Re: PROPOSAL: Permit AT_location with AT_declaration

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

> 
> We have another hypothetical situation here.   You postulate a situation
> which doesn't exist in C or C++, or any other language I'm acquainted with.
> 
> > 
> > This comment about optimization not changing semantics is off-topic.  I
> > certainly wasn't talking about any optimizations that might change semantics.
> 
> Indeed you were.  The contrived situation which you describe could
> only be the result of a program which violated the C/C++ requirement
> that optimizations not change semantics.  
> 

The language has nothing to do with it.  These are implementation choices for
the compiler.  Surely C doesn't really impose restrictions on a compiler that
it must have on canonical location for a global that can't be reused for
anything else.  After all, there's no such restriction on local objects in
registers.  

But even if C does have some heavy-handed restriction like this, DWARF2
proposes to support many languages, and I can say with certainty that Ada has
no such restrictions on the compiler.  An implementation is free to bind
variables to memory or register, to move them at will, and can do any of this
so long as the external interactions of the program remain unchanged.  A
reuse of the in-memory location of a global while the global was safely in a
register couldn't change the external interactions so long as the compiler
was careful always to move the in-register copy back to the in-memory copy
before allowing any code to execute that didn't know about the in-register
copy.

I can even see optimization value to that for an architecture that can do a
memory/register swap in the same time that it takes to do a load or store.
In that case, if it wanted to make a read/write register local copy but
retain the original value of the register too, it might see fit to swap the
memory location with the register, knowing that it would re-swap them before
exiting the routine.  This wouldn't break the semantics of the program, if
done properly, and it would cut out extra memory references by requiring 2
swaps, instead of a store for the original register value (in a different
location), a load of the global, a store of the global, and a load of the
original register value.

> > Here's another case.  If the non-defining read/write local copy describes a
> > location which merely modifies the in-memory global location, then both
> > locations are equally valid, not only for modification, but also for
> > reference.  DWARF2 makes no comment on one being "better" than the other.  So
> > a debugger wouldn't be out-of-line for choosing to read the value from the
> > in-memory location instead of the register.  (For example, maybe referencing
> > the memory location is just faster for the debugger, and it always chooses
> > the method of reference that's faster.)  Obviously, that's undesirable
> > because it will arrive at the wrong value.  The fault would lie with DWARF2,
> > because it characterized the location(s) of the global incorrectly.
> 
> Dwarf 2 places no requirement on how a debugger operates.  There are a
> few hint in places, but these are not part of the Dwarf 2 standard.
> 
> A debugger can operate as you describe, or not.  As I've often said,
> we can't insist that people write debuggers which work reasonably.
> You presume that a debugger makes choices at randomly or arbitrarily
> or foolishly, as you suggest, based on speed of access.  This is 
> certainly a design decision which you can make, but there are others.
> 

Claiming that this problem is with the debugger is just misdirection.  My
examples with debuggers are merely intended to illustrate faults in the
DWARF2.

The point is that the DWARF2 would leave the choice of locations ambiguous.
It would claim that both locations are valid for the object, when only one
is.  So, of course a debugger would have no way to know that one location was
better than the other and would have to choose arbitrarily.  The only reason
you can say that choosing an in-memory location over an in-register location
is foolish is because you know that it won't work in this example.  Probably
choosing an in-register copy would be a good heuristic, given the ambiguity,
but that's all.

> 
> We are getting even farther afield here.
> 
> I don't believe that Dwarf 2 is intended to describe anything more than
> the organization of a program.  
> 
> If your debugger makes changes to a program which would invalidate 
> the Dwarf description, then I would assume that it would have the 
> responsibility for keeping track of these changes.   This hypothetical
> situation would have it that the debugger modifies the program but
> then forgets what it did.
> 
> This is, again, a Quality of Implementation issue.  
> 

Your comments make it clear that you didn't understand the point.  The DWARF2
is lying to the debugger about the locations of variables, causing the
debugger to believe that it's free to follow the user's request and make a
safe change to the program, when in fact, it is not.  The fault would be in
DWARF2 in that case.

----------

Let me try to distill our fundamental viewpoints down here.  I may miss the
mark on yours, of course.  Correct it if I do.

It seems to me that you think the "augmentation" interpretation should be
retained because you can't think of any reason why a compiler would ever want
to describe a place where the in-memory location was invalid, nor would a
debugger ever need to know such information because it would always have some
other basis for choosing from among multiple locations that would arrive at
the correct choice.  As such, the reduction in size by not requiring location
lists is more important than the loss of the seemingly little-used additional
descriptive power.  Is that accurate?

I think that the "replaces" interpretation is better because I don't think we
should try to second-guess whether or not a compiler would want to describe
"holes" where the in-memory location is invalid, nor whether a debugger would
be able to deduce a location from among several locations described as valid
(but where only one actually is).  Instead, I think we should attempt to
provide a more general descriptive mechanism that is capable of describing
all cases.  I recognize that this would result in the need for location lists
in cases where your original proposal would not, and consider that less
important.

-- 
Todd Allen
Concurrent Computer Corporation