Issue 220724.1: Remove .debug_aranges and require unit-level ranges/high/low

Author:	David Blaikie
Champion:	David Blaikie
Date submitted:	2022-07-24
Date revised:	2024-10-14
Date closed:	2024-10-28
Type:	Enhancement
Status:	Accepted
DWARF version:	6

Comparing 2023-04-18 with latest. [ Return to the latest version ]

Section 6.1.2, pg 147

Given a discussion on dwarf-discuss (mailing lists down at the moment, so I 
can't include a link) and Clang's experience with `debug_aranges` being disabled 
by default for the better part of a decade at this point, I'd propose removing 
them from the DWARF standard in favor of adding a guarantee that CU DIEs must 
(rather than may) include a comprehensive address range (`DW_AT_high/low_pc`) or 
list of ranges (`DW_AT_ranges`). This reduces redundancy in DWARF — reducing 
debug info size and implementation complexity (having to support reading data 
from multiple/varied locations — aranges or CU DIE ranges).

While `.debug_aranges` is specified to include data ranges (in addition to
code/instruction ranges), `.debug_ranges` does not. Practical experience
from major DWARF producers has shown this to be not
necessary/used/reliable - GCC doesn't include data in `.debug_aranges`,
and Clang doesn't produce `.debug_aranges` at all by default. It would be
novel to try to put data into `.debug_ranges` (it currently is only used
for instruction addresses) and in the absence of existing usage of the
functionality, seems not worth the design work to try to add such
functionality to `.debug_ranges` or otherwise address this regression in
specified functionality.

Proposed solution
-----------------

Remove section 6.1.2 and 7.21 and all other references to .debug_aranges.

The index lists the following references to .debug_aranges: 147, 184, 186,
187, 197, 235, 274, 275, 278, 279, 366, 371, 393, 394, 399–401, 416 - these
seem to generally be easy to remove/an editorial matter of removing a 
reference from a list of examples/descriptions. (I can enumerate them all  
explicitly if desired.)

Edit 3.1.1, p61 from:

> A full or partial compilation unit entry may have the following attributes:
> 
> 1\. Either a `DW_AT_low_pc` and `DW_AT_high_pc` pair of attributes or a 
> `DW_AT_ranges` attribute whose values encode the contiguous or non-contiguous 
> address ranges, respectively, of the machine instructions generated for the 
> compilation unit (see Section 2.17 on page 51).
> 
> A `DW_AT_low_pc` attribute may also be specified in ... 

to:

> A full or partial compilation unit entry must have either a `DW_AT_low_pc` and 
> `DW_AT_high_pc` pair of attributes or a `DW_AT_ranges` attribute whose values 
> encode the contiguous or non-contiguous address ranges, respectively, of the 
> machine instructions generated from the compilation unit (see Section 2.17 
> on page 61).
> 
> A full or partial compilation unit entry may have the following attributes:
> 
> 1\. A `DW_AT_low_pc` attribute may be specified in ...

On p67, bullet 2 should be moved above the immediately preceding non-bullet text,
before line 13 (thereby making it required), and revised as follows:

> 2\. Either a `DW_AT_low_pc` and `DW_AT_high_pc` pair of attributes or a `DW_AT_ranges` attribute whose values
> encode the contiguous or non-contiguous address ranges, respectively, of the machine instructions and
> static data generated for the compilation unit (see Section 2.17 and page 61).

---

Revised: 2023-04-18

2022-07-24: [Original proposal][orig].

2023-04-18: [Revised][diff1].

2023-05-15: Accepted pending revised wording.

2024-09-23: Reopened for discussion about whether static data could or
should or must be included in the newly mandated (rather than optional)
`DW_AT_ranges`.

2024-10-14: [Revised][diff2] with new 2nd paragraph in intro section addressing
data ranges.

2024-10-28: Accepted.