Re: Modifies vs. Replaces

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

Michael Eager wrote:
>> >If Compaq's compilers generate code which has lifetime holes for
>> >global variables, could you provide a reasonable example?  Perhaps
>> >with both the source and assembly code for the example?
>> 
>> Following is a compilation listing that should illustrate lifetime holes
>> for global variables.
>
>...
>
>You don't show how you would describe this in Dwarf, so I'll
>just have to guess that you would have a location list which
>has the memory locations for addresses before the global values
>were loaded into registers, the register numbers from the 
>point that they were loaded to the point they are stored,
>and then the memory location for the remainder of the routine.

This is correct.

I didn't show what our compiler generates because, as I indicated in
an earlier discussion, we use a vendor extension that combines the
idea of overlapping lifetimes meaning distinct instances, uses LEB
encoding for offsets, and includes definition point and default location
concept (all in one); our debugger accepts that and treats DWARF V2
style location lists as a simple special case (most importantly wrt to
the overlapping lifetimes part) -- I felt it would muddy the waters
far too much to try to delve into and explain all that.

>Here's a scenario which I think is common:
>
>In your debugger, you set a breakpoint at line 14 and change 
>the value of 'k'.  Assuming that the location information is 
>as indicated above, only the "live" copy of 'k' in the register 
>would be changed.
>
>Let's say that you use a feature that is common in many
>debuggers which allows you to call an arbitrary function,
>from the debugger's context.  You call doprint(), which prints 
>the values of the globals.  When doprint references the global
>variables, it will use the memory locations and print an
>incorrect value for 'k', not reflecting the changed value.
>
>To my mind, this is not desirable behavior on the part of
>a debugger.  I would prefer a debugger to modify both the
>original 'k' in memory and the copy of 'k'.  To do this,
>it has to know that there are multiple copies which are 
>live, albeit not coherent over their entire lifetimes.
>
>Most current debuggers would only update the memory copy 
>of 'k', so that doprint() gave correct results, while the 
>computation remained unchanged.  I think that this is also 
>not a desirable behavior.
>
>I don't know that trading one undesirable behavior for another
>is a good thing.  
>
>So, how to fix this?  One way is to have location descriptions
>which describes overlapping lifetimes for both copies of 'k',
>the one in memory and the one in the register.  This way, 
>the debugger has the information necessary to update both
>copies if it wants to.

OK, suppose a debugger does that. Now when the debugger calls
doprint the value of k is correct in its global home location, but
the values of j and l are still only correct in the registers,
not in memory, so the execution of doprint may still be "wrong"
or misleading.

Merely updating all the copies of k does not solve the whole
problem. Somehow the debugger needs to know how to update all
the global variables that doprint might possibly (or at least actually)
reference to their memory locations. Moreover, this is a transitive
requirement that must handle anything that doprint might (or
actually) calls.

Further, the relevant values are not necessarily all in the current
routine--every routine in the stack needs to be considered. And
if there are multiple threads in the same process, then every
stack in every thread...

Moreover, updating k is the easy case in that the new value of
k is readily in hand in the debugger. Updating all the other
variables leads to the requirement for a rule along the lines
suggested by Jim in his follow-on mail so that the debugger
unambiguously knows which of the several locations associated
with a variable should be used to update the others.

[I'll have more to say about Jim's responce separately.]

>I'll also note that there appears to be no harm to the program's
>execution by updating both the memory and register contents.

In this particular example, yes. But the general case gets far more
complicated...