Re: Rewrite of PROPOSAL 001213.1 re default location

[Michael Eager <eager at eagercon dot com>]

David B Anderson wrote:
> 
> M. Eager writes:
> >There are few circumstances I can think of that a compiler
> >would generate code where there are two identical instances
> >of an object with overlapping lifetimes.   In most cases,
> >there is what I might call a primary copy of the variable
> >(i.e., the one in memory) and a working copy (the one in
> >a register).  Dave's examples represent both of these cases.
> >
> >One can't reasonably chose to access only the primary during the
> >lifetime of the working copy.  One has to describe all of the
> >places where the object exists if one wishes to provide a debugger
> >with adequate information to be able to correctly display or
> >modify an object's value.
> 
> Whether lifetimes overlap or don't, as long as one
> ignores the situation where multiple distinct instances
> with the same name
> exist at the same time (which has nothing to do
> with Ron's proposal and is a situation that DWARF2 does
> not address) one can already describe everything
> using location lists.
> 
> (I'll presume I actually understand the issue here...)
> 
> Ron is not suggesting that the existing location list
> is inadequate.
> Ron is suggesting that for what is a real situation
> in practice (for compilers and optimizers he is familiar with)
> there is a description which is more compact.
> 
> Consider the following trivial example.
> 
> int v = z                               point A, a springs into life.
> 
>         v moves to a register     point B.
>                 v = y[k];            point C.
> 
> 
>         v copied back to original loc  point D.
> 
> End of life of v, point E.
> 
> It's perfectly possible to describe this adequately with
> dwarf location lists (in this case it takes 3 loclist entries,
> but is most clearly shown as 4 lines).
>   A to C, current in original location (only).
>   B to C, current in register (ie, in both locations from B to C)
>   C to D, current in register (only)
>   D to E, current in original location (only).
> 
> This however misses the essential claim (lets hope I have this
> paraphrase right):
> That a variable whose home location is  at address 0x1234,
> and which lives for possibly many short periods in a register,
> is more compactly represented by
>    a default location plus location lists describing
>    times when the default location is not the current location
> than by
>    An explicit complete location list.

Exactly what would be the description based on the proposal?

How do you distinguish the cases where v is in two places (from B to C)
from where it exists only in a register (from C to D)?  (It appears to
me that the proposal does not anticipate the latter circumstance.)

> This claim based on implementation experience (it is not hypothetical).
> 
> The original proposal states that the space saved is significant.

It would appear that your example would use a default location attribute
and two location attributes.  Unless I'm missing something, this is not
smaller.  If there are more occasions where you change the allocation for
v, a location list entry is added in either case.  
 
> The original proposal removes no capability of location lists.
> 
>   Aside:Note that if a vendor uses the proposed facility (as a vendor
>         extension) debuggers not knowing about the facility
>         are significantly impaired as they would ignore the default
>         location.

Yes, this would be an incompatible change.

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