Re: Rewrite of PROPOSAL 001213.1 re default location

[Michael Eager <eager at eagercon dot com>]

DAVID WEATHERFORD wrote:
> 
> I believe the text of the document in 2.5.4 that describes
> overlapping ranges was intended for just the situation that
> Ron is addressing.  I have a hard time imagining what it
> would mean for both the outer and inner locations to be
> current.  I take it to mean that the debugger should read
> the value from the innermost, and write any modifications
> to *all* the locations which are active at the current PC.
> 
> There are two variants of nested ranges:
> 
>         (1) Let's call the outer static address &x; when
>         the code looks like
> 
>                 load &x, %r5
>                 [ lots of reads of %r5 ]
>                 return
> 
>         then both outer (&x) and inner (%r5) are live,
>         and the debugger must update *both* if the user
>         assigns a new value to x while the program is
>         in the inner region.  Otherwise the new value
>         will be lost when the current function returns.
> 
>         (2) If the code looks like
> 
>                 load &x, %r5
>                 [ lots of reads of %r5, and a few writes ]
>                 store %r5, &x
>                 return
> 
>         then, although, strictly speaking, the outer
>         location is not "live", the debugger should still
>         update both locations when the user assigns to
>         x, because accesses from other scopes (previous
>         frames, or a global watch, for example) will see
>         the static location and the user could become
>         confused ("But I just changed x to 17, why does
>         it still say 12???").
> 
> Can anyone provide another plausable interpretation of
> the current description?

Dave offers essentially the same examples that I would.

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.


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