Re: PROPOSAL: Permit AT_location with AT_declaration

[Michael Eager <eager at eagercon dot com>]

Todd Allen wrote:
> 
> But if the "modifies" wording is kept, there's a loss of functionality.  If
> the "replaces" wording is used, it might mean that location lists would be
> required in more cases, but a class of very common cases can be described.

If the following is supposed to demonstrate a functionality which would
be lost, let me assure you that the argument is lost on me.  Clearly 
the example you give can be correctly described. 

> In particular, consider the case where there's a read/write local copy, as in
> this example:
> 
>    myfunc()
>    {
>       extern int x;
> 
>       for (; x < ...; x++) {
>          ...
>       }
>    }
> 
> which is optimized to (with x' being the local copy):
> 
>    myfunc()
>    {
>       extern int x;
> 
>       x' = x;
>       for (; x' < ...; x'++) {            // (1)
>          ...
>       }
>       x = x';                             // (2)
>    }
> 
> Between locations (1) and (2), inclusive, the global in-memory location of x
> is inaccurate (at least after the first iteration of the loop).  So,
> including it as a live location, as the "modifies" wording implies, is
> incorrect.  As someone pointed out in the previous location list discussion,
> a perverse optimizer might actually be using the global in-memory location
> for something else between (1) and (2).

You seem to suggest that the memory location allocated to a global variable
in one compilation unit might be reused for a different variable in a 
different compilation?  Indeed, to use your description, this is perverse.
I would venture a guess that no such optimizers exist.

Is this one of the "class of very common cases" to which you refer?

> Because, given the "modifies" wording, the DWARF information would be
> indicating that both locations were live, if a modification to x were
> attempted by the debugger while stopped in the loop, the debugger would have
> to modify both the in-memory and in-register locations.  It couldn't know
> there's an assignment x = x' later on.  In fact, there could be an execution
> path where x' never did change and the optimizer cleverly skipped it.  The
> debugger's modification would be incorrect because it would be changing a
> location that wasn't really associated with the variable x at that moment.

One of the precepts of C and C++ is that optimization does not change
the semantics of a program.  Whether or not there is a copy of the global,
and whether or not the memory location for the global is re-written, the 
semantics remain the same.   

In your hypothetical situation where there was a path in which the 
the memory location did not get re-written, if a debugger were to 
change the value only in the copy I would consider this to be
incorrect.  (Indeed, the most common behavior I have seen in debuggers
is to modify only the memory location, and not the copy, which is 
also incorrect.)  Modifying the value both in the copy and in the 
memory location would be the only reasonable behavior for a debugger,
in my opinion.

On the other hand, what differentiates successful products from 
the unsuccessful products are decisions such as this.  Certainly
a debugger which you design could chose to only modify the location
mentioned in the non-defining declaration, if you wished it to 
work in that fashion.  How your debugger chooses to handle object 
which exist in more than one location at the same time is a matter 
of implementation choice.




If you are done with these hypothetical situations, can we move on?


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