Re: PROPOSAL: Permit AT_location with AT_declaration

[todd dot allen at ccur dot com (Todd Allen)]

> 
> No, modifies is correct; replaces is incorrect.
> 
> For example, if you had code which looked like the following:
> 
> 	void myfunc() 
> 	{
> 	   extern int x;
> 	   { 
> 	      // use of x, where a copy is kept in a register
> 	   }
> 	   . . .	// x is only in memory here
> 	}
> 
> If one uses location lists, as you suggest, I guess that one could 
> add an entry for the memory location.  But this would be (a) 
> redundant and unnecessary since it only repeats the location which
> is given in the definition, and (b) require the use of location 
> lists where they would not otherwise be required.  
> 
> Changing "modifies" to "requires" would prohibit the use of 
> location expressions to describe locations in non-defining 
> declarations.
> 

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.

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

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.

-- 
Todd Allen
Concurrent Computer Corporation