Issue 180326.1: Clarify consistency of DWARF 32/64 format with a CU
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
