Re: Rewrite of PROPOSAL 001213.1 re default location

[Michael Eager <eager at eagercon dot com>]

I can't understand why Ron's proposal makes no comment on the text in 
the standard which refers to overlapping address ranges, even when this 
was specifically mentioned at the last committee meeting.  

Here the relevant text from the draft standard (Draft 5, Section 2.5.4, page 25):

	Address ranges may overlap. When they do, they describe a 
	situation in which an object exists simultaneously in more than 
	one place. If all of the address ranges in a given location list 
	do not collectively cover the entire range over which the object 
	in question is defined, it is assumed that the object is not 
	available for the portion of the range that is not covered.

The only ambiguity that I see is what should a Dwarf consumer do when
an object exists in more than one place.  It appears that the consumer
would have the choice to use any copy of the object.  

It would appear that resolving this ambiguity would resolve this issue.

Insert the following after the second sentence in the above paragraph:

	"When address ranges overlap, the specification for the latest 
	encompassing address range should be used to reference the object."

(I had thought to indicate "most restrictive address range", but this has 
it's own set of ambiguities.  There may be a better word than "latest".)

DAVID WEATHERFORD wrote:
> 
> Sorry, Ron, I still don't get it.  The current definition of location
> lists covers exactly this case by allowing overlapping ranges.  For
> your example, the entries should be
> 
>      1       (<beginning of module>, <end of module>+1)
>                                         static address &x
> 
>      2       (<first assignment>,  <second assignment>)
>                                         register Ri
> 
>      3       (<second assignment>, <routine exit>)
>                                         register Rj
> 
> On the phone you objected to this interpretation of the current
> spec.  What exactly do you think the above means, then?
> 
> I'm sorry I didn't comment earlier, but I was gone or swamped for all
> of December.
> 
> Dave W.
> 
> Ron 603-884-2088 wrote:
> >
> > Here is the rewrite of 001213.1 as requested at the 9 January DWARF meeting.
> >
> > --------------------------------------------------------------------------------
> >
> > 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.
> >
> > In email of 30 November I solicited feedback regarding this alternative
> > and the proposal above, but got no responce. I choose the separate
> > DW_AT_default_location list approach to propose because it seems more
> > intuititive and seems more likely to be reliably ignored by a pre-DWARF
> > V2.1 consumer.
> >
> > (On the other hand, other proposals related to location
> > lists and discontiguous scopes, namely 001101.1 and 001130.1, may
> > complicate the interpretation of locations lists for other reasons so
> > that the extra complication of this alternative might be considered
> > acceptable. However, other than affecting the same structure, this
> > alternative is independent of those other proposals.)
> 
> --
> Dave Weatherford                Forte Tools
> David.Weatherford@Sun.COM       Sun Microsystems, Inc.


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077