Problem Statement
-----------------

The problem statement is unchanged from the proposal of 001101.1.
However, the discussion indicated a preference for an additional
constraint--that the current .debug_aranges section not become
even "sometimes required" for an additional purpose beyond its
original optional fast lookup goal.

Felix suggested the following: Instead of using the pseudo-address
range (N, 0) to indicate a switch to the Nth segment (found in
.debug_aranges), use the pseudo-address range (MAX_ADDRESS, B),
where MAX_ADDRESS is either 0xFFFFFFFF or 0xFFFFFFFFFFFFFFFF
according to the target address size, to indicate a switch
to the new base address B.

With this approach, a revised proposal would look like the following:


PROPOSAL
--------

There are several parts:

1)  No changes to 000914.1 as previously approved, except that the
    DW_AT_entry_pc attribute is not relevant. (Recall that 000914.1
    was amended during discussion--see the minutes for 3 October 2000.)
    As a result, there is no reason to allow DW_AT_entry_pc on a
    compilation unit DIE.

2)  Define a means to use the low-address/high-address pair of
    range lists and location lists to indicate
    which base address applies. To do this, note that every valid
    address range (L, H) satisfyies the relation L < H. Thus,
    any pair for which this relation does not hold can be defined
    to have some other interpretation. One such interpretation is
    already defined: the pair (0, 0) indicates the end of list.

    Define a "base address selection entry" to consist of the pair
    (MAX_ADDRESS, B) where MAX_ADDRESS is the largest address possible
    on the target (either 0xFFFFFFFF or 0xFFFFFFFFFFFFFFFF). It follows
    that MAX_ADDRESS > B. This entry specifies that subsequent entries
    in the same range or location list are defined relative to the
    address B (until the next selection entry is encountered, of course).

    If the containing compilation unit is contiguous, then the first
    entry is assumed to be relative to the low address of the compilation
    unit (no base address selection entry is required in such a unit).
    Otherwise, every location and range list must begin with a base
    address selection entry.

        [There is potential for optimization here. The base address
        might default to an address that is in some way associated
        with the innermost containing scope or procedure. For
        simplicity, this is not proposed.]

    For a location list, there is no need to append a fake DWARF
    expression (eg, a 2-byte count of zero) in a (misguided) attempt
    to make the base address selection entry "look like" a location
    entry. The ability of dumpers to scan and interpret the location
    list section independent of other information is not compromised
    by this omission.


Discussion
----------

There are numerous advantages to this proposal, including:

1) It solves the relative address relocation problem.

2) It is upward compatible with DWARF V2.

3)  The ranges list information for a discontiguous compilation unit
    will be redundant with, and actually larger than, the correspoding
    .debug_aranges information, IF the latter is present.

    Each separate test section of a compilation unit DIE
    (DW_TAG_compile_unit) will require two entries in its corresponding
    ranges list:

        (MAX_ADDRESS, B) (0, L)

    where B is the base of the segment and L is its length. The first
    entry establishes the base of the segment while the second specifies
    the range using the "relative addresses" zero and L.

4)  If the problem were specific to range lists and not location
    lists, we might rethink 000914.1 from the ground up and consider
    other approaches that did not involve "tricks" based on the
    nature of address ranges. However, the problem exists in DWARF V2
    (even before the 000914.1 proposal) so it is critical to formulate
    a solution that works for location lists as well. This proposal
    does.

5)  This representation is easy for a compiler to generate. Note that
    the base addresses entries can be nothing more
    than the 0'th address in each respective "text" section and the
    relative addresses used in location and range list address pairs
    are then nothing more than the (local) section offsets within those
    respective sections. [Other producer choices are possible, but
    there appears no reason to.]

6)  Compared to the original proposal in 001101.1:

    - There is no difference in size for location lists and range
    lists (well almost--the earlier proposal established a default
    base even for discontiguous units while this one does not;
    but it could).

    - The base address selection entries in this proposal require
    associated relocations in the underlying object representation,
    while the earlier proposal does not.

    - This proposal has no dependence on the .debug_aranges section.

This proposal is replaced by 010119.1.