Re: Rewrite of PROPOSAL 001213.1 re default location

[brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)]

Dave,

>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.

Hopefully my previous mail provides the examples that respond
to this. There is certainly nothing in the DWARF text that
suggests any kind of nesting or ordering or priority or whatever.
And, as I hope I explained, there is very good reason why it
should not.

>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.

I consider this a different situation. In this case %r5 is "merely"
a cache for a copy of the value of x. I would expect that %r5 is
not and should not be described in any location list entry for x.

But how then would I support a debugger assignment to x? I would not.
That problem is so hard that I think even an ambitious debugger that
purports to help the debugging of optimized code should disallow it!
Just imagine trying to update all the state where the value of x
has been used in the calculation of some other intermediate result
(finding cached copies is trivial by comparison); even knowing that
this has happened (let alone how to undo and redo such calculations)
is itself a non-trivial challenge.

>	(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???").

Since the outer location is not live, why update it? Since it is
not live, why should the user even be seeing it in the first place?
As I suggested previously, that piece of storage may not even be being
used for x during the time that x "lives" in %r5.

>Can anyone provide another plausable interpretation of
>the current description?

Hopefully I have done just that.

Ron