Re: PROPOSAL: Permit AT_location with AT_declaration

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

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

Your argument seems to be that you can't imagine any compiler doing that.  I
believe arguments based on second-guessing the compiler are flawed.  The
"modifies" wording reduces the descriptive power of DWARF2 based on your
assumption that no compiler will ever have to describe a local copy such that
the global in-memory location should not be modified or referenced.

If the DWARF2 is capable of describing such a situation, then a debugger
which encounters such a description and still modifies the global in-memory
copy is exhibiting wrong behavior, and that's just a debugger QoI issue.  If
the DWARF2 is incapable of describing such a case when it's needed, then the
deficiency lies with DWARF2.  I see no reason to create a deficiency in
DWARF2 intentionally.

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.

Here's another concrete situation where it could make a difference.  Our
debugger, and probably others, are capable of inserting "patchpoints", which
are small pieces of code that are inserted into the program that run without
debugger intervention.  Consider a patchpoint that references a global
variable that has local copies.  The debugger, in general, cannot know that,
when a particular patchpoint is executed, there are not local copies in
existence in some outer stack frame (which an optimizer doing interprocedural
analysis could create), because there may be many ways for the routine
containing the patchpoint to be called.  If there exist any locations capable
of calling the routine containing the patchpoint, then there are cases where
the patchpoint would be executed where the global in-memory location is
inaccurate for a time, because a read/write local copy exists.  A debugger
would want to have this information so that it could indicate to the user
that such a patchpoint was unsafe.  However, if no such locations exist, it
can safely insert the patchpoint.  With your "modifies" wording, the DWARF2
would be indicating that the global's in-memory location always was valid,
regardless of whether or not that was true.

I probably could dream up some more cases, too.

Standing back from the issue of how debuggers would use this information,
your "modifies" wording forces compilers to emit DWARF2 for programs with
read/write local copies to describe lies.  Maybe those lies won't hurt a lot
of consumers.  But that isn't the point.  The DWARF2 should permit a correct
description.

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

This comment about optimization not changing semantics is off-topic.  I
certainly wasn't talking about any optimizations that might change semantics.

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

This also is off-topic.  You're talking about how a debugger might choose to
misinterpret DWARF2.  I'm talking about the descriptive power of the DWARF2
itself.

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

This condescension is inappropriate.

-- 
Todd Allen
Concurrent Computer Corporation