Re: Modifies vs. Replaces

[Michael Eager <eager at eagercon dot com>]

Ron 603-884-2088 wrote:
> 
> 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.
> 
> Lines begining with ">>>" are annotations that I added to help explain
> what is going on in the code.
> 
> I believe everything shown is consistent with what Jim Denhert described
> (and what I was trying to describe, perhaps less well).

Thanks.  

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.

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.

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

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