This proposes an optimization to the representation of location lists.
Recall that location lists are defined in DWARF V2 to represent the
locations of variables that change over time (sometimes referred to as
"split lifetime variables"). The proposal provides for the description of a
default location to be used if no location in the location list applies.

In DWARF V2, location lists are defined in Sections 2.4, 2.4.6 and 7.7.2.
They can be referenced from a DW_AT_location attribute that has a value of
class constant, and similarly from several other attributes whose
exact identity is somewhat unclear.

In DWARF V2.1 Draft 5, location lists are defined in Figure 3 (see
specifically loclistptr), Sections 2.5, 2.5.4, 7.5.4 (see specifically
loclistptr) and 7.7.3. They can be referenced from a DW_AT_location
attribute that has a value of class loclistptr, and similarly from
attributes DW_AT_string_length, DW_AT_return_addr,
DW_AT_data_member_location, DW_AT_frame_base, DW_AT_static_link,
DW_AT_use_location and DW_AT_vtable_elem_location.


PROBLEM STATEMENT
-----------------

Consider:

    extern int x;

    void Foo() {

        x = ...              \
                             > Lifetime segment 1
        ...use(x)...         /

        x = ...             \
                            \
        ...use(x)...          > Lifetime segment 2
                            /
        ...use(x)...        /

        return;                 Update default
    }

An optimizing compiler might exploit this sort of example by dividing
the lifetime of x into several parts: One segment begins at the first
assignment to x and extends until the second. Another segment starts
at the second assignment to x and extends to the routine exit. Finally,
since x is permanently allocated and everywhere visible, additional
segments are needed to describe everything not covered by the first
two segments. The first lifetime segment can easily be allocated in
a register. The second lifetime segment can also, provided that the
compiler copies ("spills") that local segment value back to the
"permanent" external location when exiting Foo.

Surely this situation can be easily described using the existing
location list representation, right? The answer is "Yes, but...".

Consider what that representation needs to look like:

    Segment     Address range          Location
    -------     -------------          --------

       1         (<beginning of module>, <first assignment>)
                                      static address &x

       2         (<first assignment>, <second assignment>)
                                      register Ri

       3         (<second assignment>, <routine exit>)
                                      register Rj

       4         (<routine exit>, <end of module>+1)
                                      static address &x

Actually, there might a "space" between segments 2 and 3 where the
active lifetime must resort to the permanent location (for example,
due to a subroutine call).

Thus, in general, if there are N register lifetime segments there may
need to be as many as N+1 additional segments, describing in effect
the complement of the union of those register segment ranges; moreover,
all of those additional segments necessarily specify the same location.

This suggests that it would be attractive to have a means to express
a default location -- a location that applies when none of the others
are "live".


PROPOSAL
--------

Introduce a new DW_AT_default_location attribute whose value is a
location expression, represented using either class address or block.
(By its nature, a location list is not meaningful for this attribute.)

This attribute may be used (only) in conjunction with the DW_AT_location
attribute, or any other attribute for which a location list is allowed,
when that attribute actually refers to a location list.

The DW_AT_default_location is interpreted as follows: When a location
list is searched to find an applicable location or set of locations that
correspond to a given address in the program and no location is found,
then the referencing DIE is examined to see if it has a DW_AT_default_location
attribute; if it does, then the value of that DW_AT_default_location is
used as the applicable location, otherwise there is no applicable
location.

Note that this proposal does not affect the representation or
interpretation of location lists as such; however, it does augment the
rules for searching and using locations lists. This proposal does not
affect the meaning or use of attributes whose value is a location list
other than to indicate that the result of evaluating the attribute for
a specific address (PC) may be found in an associated
DW_AT_default_location attribute, if any, if not found in the location
list as such.


DOCUMENT CHANGES
----------------

The document changes (for V2.1 Draft 5) are:

  - Add DW_AT_default_location to Figure 2.

  - At the end of Section 2.5.4, Location Lists, insert

    When the location of an object is such that it has a particular
    location that applies everywhere other than within a specific
    list of address ranges, that location can be specified in two
    parts: the normal location attribute (such as DW_AT_location)
    which uses a location list to specify the locations associated
    with the specific address ranges and a DW_AT_default_location
    attribute which specifies the location that applies everywhere
    else.

    <italics>In the general case where an object is allocated in
    a static location but may temporarily live in a register from
    time to time, a representation of this information using only
    a location list would need, say, N entries to represent the
    register lifetime segments and up to an additional N+1 entries
    to represent where the static location applies. Use of the
    DW_AT_default_location attribute saves space by representing
    only the N register lifetimes in the location list and by
    representing the static location just once as a "default"
    location.</italics>

    If a debugging information entry has more than one attribute
    whose value is a location description that is a location list,
    then the DW_AT_default_location attribute must not be used.

  - In Section 2.15, Data Locations, add (following the current
    single sentence)

    If that location description is a location list, then the data
    object may also have a DW_AT_default_location attribute whose
    value is a location (see Section 2.5.4).

  - In Section 4.1, Data Object Entries, bullet 3, insert "and/or
    DW_AT_default_location" in the final sentence so that it reads

    The location of a variable may be further specified with a
    DW_AT_segment and/or DW_AT_default_location attribute, if
    appropriate.

  - In Figure 18 (in Section 7.5.4, Attribute Encodings) add

    DW_AT_default_location <next code> address, block

  - In Figure 38 (in Appendix A) add attribute DW_AT_default_location
    to the list of applicable attributes for the following TAGs

        TAG                      Reason(s)
        ---                      ---------

    DW_TAG_entry_point           DW_AT_frame_base,
                                DW_AT_return_addr,
                                DW_AT_static_link

    DW_TAG_formal_parameter     DW_AT_location

    DW_TAG_inlined_subprogam    DW_AT_return_addr

    DW_TAG_member                DW_AT_data_member_location

    DW_TAG_subprogram            DW_AT_frame_base,
                                DW_AT_return_addr,
                                DW_AT_static_link

    DW_TAG_variable              DW_AT_location


DISCUSSION
----------

We (Compaq) have used this concept of a default location to good
advantage on several systems (VMS, Tru64 eCOFF, and Linux [the last
using a vendor-defined DWARF attribute]) and find that it can and does
result in a useful savings in debugging symbol table size.

Examination of Appendix A (Figure 38) indicates that there are currently
just two TAGs (for entry points and subprograms) that allow more than
one attribute that might use a location list (for frame base, return
address and/or static link). Of course, new TAGs and/or attributes
defined in the future might also create this possibility. To deal with
this possibility, it suffices to specify that the DW_AT_default_location
must not be used if it would be ambiguous to which location list it
applied. Since DW_AT_default_location functions purely as a space
optimization, it is always possible to do without it and not lose any
information. (By far the dominate use and benefit of
DW_AT_default_location will be in combination with DW_AT_location for
the DW_TAG_variable DIE; any limitations on its use or applicability
in other cases will hardly matter.)


ALTERNATIVES CONSIDERED AND REJECTED
------------------------------------

An alternative representation that could be used to achieve the same
semantics would be to allow the last entry on a location list to
optionally specify a default location. The low-address/high-address
part of such an entry could be encoded in some way that makes it an
invalid range, for example (1,1) or (max-address, max-address) just
to be concrete. Encountering this special range would be interpreted
as meaning: if any applicable entry (one or more) has been found prior
to this point, then ignore this final entry; otherwise, no applicable
entry has been found up to this point, so use the location in this last
entry as the (only) location.

The advantage of this approach is that it combines the full split
lifetime and default location information all in the same structure.
A disadvantage is that it complicates the interpretation of the range
part of the location list entry.

Withdrawn by submitter.