Re: Modifies vs. Replaces

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

Jim Dehnert wrote:
>Michael Eager wrote:
>> 
>> I'll also note that there appears to be no harm to the program's
>> execution by updating both the memory and register contents.
>
>That's true, as long as the memory isn't used for something else in
>the meantime (quite unlikely).  But it's important that the debugger
>_read_ the value from the register -- the two locations aren't
>equivalent for this purpose.  This was why I suggested, back during
>the default value discussion, that a possible treatment was to say
>that a designated element of a list of overlapping ranges (probably
>the first, maybe the last) be considered primary for reference, but
>that all must be updated.

I agree that it is "quite unlikely" for the global home location to be
used for some other purpose during the time that the "real" value of
the global variable is somewhere else.

Moreover, I guess there is no loss of generality here. If the global
location should not be updated then it need not be described using
an address range of 0..MAXADDR; it can be described by two (or more)
entries that describe the set of ranges where it is appropriate to
be updated.

>This also copes well with a more problematic example I brought up at the
>time.  Suppose again that you have a variable with an allocated memory
>location.  A new value is assigned to it, and the following events occur:
>
>	a:  x.reg = new value
>	...
>	b:  x.mem = x.reg (store to home location)
>	...
>	c:  ... = ... x.reg ...
>	... x.reg is dead ...
>	d:  load x.mem
>
>Between points b and c, x is live in both the register and memory.  Its
>value may be read by a debugger from either place, and must be updated
>in both places.
>
>So my personal bias for the rule we're discussing would be:
>
>	The defining instance's global location is always potentially live,
>	and must therefore be updated.
>
>	The non-defining instance's location(s) take precedence for
>	addresses within the specified range(s); only the first one
>	encountered with the desired address in range is guaranteed
>	to have a valid value for reference, but all must be updated.
>
>This would effectively make the global location a default location, to
>be used whenever there is no other matching address range.  It's a
>compact representation, since the non-defining instances only need to
>specify temporary locations that override the global one.  It does
>require, though, that a debugger look up the defining instance even
>if it finds a matching local non-defining one.

This rule, while definitely getting better than earlier suggestions, still
does not cover the full glory of the update problem. Let me extend the
example by making line c more specific and adding line e so that we get

	a:  x.reg = new value
	...
	b:  x.mem = x.reg (store to home location)
	...
	c:  cse.req = ... x.reg + 1	// instead of ... = ...x.reg...
	... x.reg is dead ...
	d:  load x.mem
	...
	e:  y.req = ...cse.req...	// additional line

Suppose between whatever instruction that kills the value in x.req and d,
we tell the debugger to update x? At this point, the only location live
for x is x.mem so that is all that is updated. That takes care of x, but
now what about y? The cse (common subexpression) held in some register
has already incorporated the old, now superceded value of x. If we (the
debugger) fail to update the cse.req location, then the subsequent
assignment to y (whether in a register or memory) will give it a value
inconsistent with what it should be, based on the value of x.

This is not to say that I am opposed to Jim's suggestion. Actually, I
think it is the best suggestion so far for a representation/interpretation
that improves the descriptive power of DWARF location lists.

Neither do I want us (or readers of the DWARF specification) to thing that
DWARF location lists provide a means to handle the variable update problem
in its full generally.

I stated once upon a time that this problem is hard in optimized code. I
say it again. I'm not aware of any design that even makes it possible to
precisely distinguish those cases where a variable can correctly be
updated at any give program counter vs those where it cannot. Certainly
far more required to achieve even that much than we are discussing
here.

[A very pessimistic "approximation" is to disallow debugger assignment
altogether for optimized code--it is at least safe, even if it does toss
part of the baby out with the bath water!]

With that understanding, I'll still support Jim's suggestion and leave
to ambitious implementers the design of vendor extensions that allow
a more complete solution.