DWARF Standard


HOME
SPECIFICATIONS
FAQ
ISSUES



030318.1 David Anderson DW_AT_ranges and address size Clarification Accepted with modification Dave Anderson


Fred Riss
|I was reading Dwarf3 draft 8 and came across what seems to be an
|inconsistency in the .debug_ranges section contents description. In
|section 7.24 I read that all entities of the .debug_ranges section are
|sized like an addressing unit (= the address size defined by the
|compilation unit header). Now in section 2.16.3, the 'base address
|selection' entry is defined to begin with 0xFFFFFFFF in DWARF 32bits and
|0xFFFFFFFFFFFFFFFF in DWARF 64bits... and what if the address size of a
|target is 16 bits ? 
|I think the standard wants the base selection entry to be 0xFFFF
|followed by the base address, am I wrong ?
|
|It could be that the text in section 2.16.3 doesn't refer to the Dwarf
|format (Dwarf3 32/64 bits described in section 7.4), but to Dwarf files
|using 32/64 bits addresses ; the statement would then be right, but if
|that's the right interpretation, I find the reference to Dwarf 32/64bits
|format very confusing for the reader.


David Anderson
2.16.3 does mix up the notions of address and offset.
The description of 'base address' uses offset terminology and 
values.

While for most architectures a value of 'all bits on' would
be a suitible special-value to describe a 'base address selection entry',
that is not universally true.

Proposal by David Anderson
PROPOSAL:

The description of a base address selection entry (the 1. part)
be changed to

1.  A special distinguished value (not a value that would
    be used as a data or code address).
    
    For most architectures, a value of 0xffffffff for 32 bit pointer
    addresses (0xffffffffffffffff for 64 bit pointer addresses)
    will work and is the value defined by this document.

    For architectures for which these values are inappropriate,
    the ABI committee or compiler author 
    may define a distinguished value. If a
    distinguished value is not defined a compiler must not emit
    Non-Contiguous Address Ranges.  



In the intro paragraph of 2.16.3, add

Not every architecture can necessarily support range lists.
See the definition of a 'base address selection entry'
(which is described below).

----------------------------------------------------------

Proposed wording:
Here is the wording I suggest in 2.16.3, page 32:

    A range list entry consists of:

      1. A beginning address offset. This address offset has the
         size of an address and is relative to the applicable
	 base address of the compilation unit referencing this
	 range list. It marks the beginning of an address range.

      2. An ending address offset. This address offset again has
         the size of an address and is relative to the applicable
	 base address of the compilation unit referencing this
	 range list. It marks the first address past the end of
	 the address range.The ending address must be greater than
	 the beginning address.

    ...

    A base address selection entry consists of: 

      1. The value of the largest representable address offset
         (for example, 0xffffffff when the size of an address is
	 32 bits).

      2. An address, which defines the appropriate base address
         for use in interpreting the beginning and ending address
	 offsets of subsequent entries of the location list.


Nearly identical changed wording is also used back in Section 2.5.4,
pages 24-25, regarding location lists (not shown here).


Accepted as modified.



All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2017 by DWARF Standards Committee.