Re: dwarf 2.1 .debug_ranges

[Daniel Berlin <dan at cgsoftware dot com>]

Richard Henderson <rth@redhat.com> writes:

> Is the dwarf 2.1 committee still meeting?
> 
> IMO there is a serious flaw in the formulation of DW_AT_ranges
> and the associated .debug_ranges section.  The same flaw exists
> with location lists, but they're in dwarf 2.0 and therefore
> harder to fix.

Errr, I don't believe there is a flaw in the location lists.
In dwarf 2.0, there would be, if we had discontiguous ranges.
However, in 2.1, you can specify the base address through a base
address selection entry.
"
The applicable base address of a location list entry is determined by the closest preceding base
address selection entry (see below) in the same location list. If there is no such selection entry,
then the applicable base address defaults to the base address of the compilation unit (see
Section 3.1).
"
We actually know how to output these for location lists, see
dwarf2out.c (I implemented it, or at least, tried to, looking at it
now, i think i have the strcmp test backwards)

The problem with the ranges seems to have occurred because the
original proposal specified that the ranges should point to a location
list in the debug_loc section, rather than make a new section.  Had
this been done, the base address would selected the same way.


> 
> To wit:
> 
> 	2.16.3 Non-Contiguous Address Ranges
> 	1.  A beginning address. This address is relative to the base
> 	address of the compilation unit referencing this range list.
> 
> (1) What is the "base address" of a non-contiguous compilation unit?
> 
> (2) Why should we even bother with relative addresses here?
>     We're quite happy with absolute addresses for DW_AT_low_pc.
> 
> (3) Why is this being done in a separate section with terminating 
>     nulls, etc?  Address ranges for functions and lexical blocks are
>     basically never shared.  I suppose there are some degenerate 
>     cases of { int x; { int y; foo(); } } where there is no extra
>     code in the outer lexical block.  However, it would seem just
>     as easy in this case to represent this with a single lexical block.
> 
>     It would seem to require less space to have DW_AT_ranges to use
>     DW_FORM_block of size 2*DWARF2_ADDR_SIZE that contains the begin/end
>     pairs.  This elimintes the DW_FORM_data4 offset into .debug_ranges
>     and the pair of DWARF2_ADDR_SIZE zeros that terminate each list.
> 
> As far as location lists go, I'd suggest that for backward compatibility
> the begin/end ranges be relative to the compilation unit iff the 
> compilation unit has a DW_AT_low_pc.  If it doesn't, as with functions
> in different sections, then the addresses should be absolute.
> 
> Thoughts?
> 
> 
> r~

-- 
"I went into a clothes store the other day and a salesman walked
up to me and said, "Can I help you?"  and I said "Yeah, do you
got anything I like?"  He said, "What do you mean do we have
anything you like?"  I said, "You started this."
"-Steven Wright