# 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

2022-05-16:  Superseded by [211101.1][211101.1].

[211101.1]: https://dwarfstd.org/issues/211101.1.html