DWARF Standard

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