dwarf 2.1 .debug_ranges

[Richard Henderson <rth at redhat dot com>]

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.

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~