Issue 180326.1: Clarify consistency of DWARF 32/64 format with a CU
| Author: | Paul Robinson |
|---|---|
| Champion: | Paul Robinson |
| Date submitted: | 2018-03-26 |
| Date revised: | 2021-05-03 |
| Date closed: | 2021-06-28 |
| Type: | Clarification |
| Status: | Accepted |
| DWARF version: | 6 |
Section 7.4, pg 198
PROBLEM DESCRIPTION
Given that most DWARF sections begin with an initial-length that specifies whether it uses the DWARF 32-bit or 64-bit format, it can be a bit of a surprise that we always intended a producer to use the same format across all sections for a compilation. And, now that we have some attributes that do not point to the initial-length field but to the relevant data within the body of a section, this consistency becomes more important.
DWARF 5 section 7.4 p.198 lines 14-17 currently state:
The 32-bit and 64-bit DWARF format conventions must not be intermixed within a single compilation unit.
Attribute values and section header fields that represent addresses in the target program are not affected by these rules.
RESOLUTION
Remove the above text from p.198, and instead put it on p.196 immediately following the first paragraph of section 7.4 (i.e., insert the text at line 10), and add a new non-normative paragraph. Then the three paragraphs would read as follows:
The 32-bit and 64-bit DWARF format conventions must not be intermixed within a single compilation unit.
This rule greatly simplifies parsing DWARF in some cases. For example, the DW_AT_str_offsets_base attribute points to the zeroth entry of the string offset array, not to the header of that portion of the .debug_str_offsets section, making it inconvenient to determine the size of the entries in the array. By requiring that the referencing compilation unit and the referenced array use the same format, a consumer can know the array entry size without needing to find the .debug_str_offsets header.
Attribute values and section header fields that represent addresses in the target program are not affected by these rules.
2021-05-03: Minor revision
2021-06-28: Accepted
2022-05-16: Superseded by 211101.1.
