Re: PROPOSAL: Permit AT_location with AT_declaration

[Michael Eager <eager at eagercon dot com>]

Todd Allen wrote:
> 
> >
> > 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.

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.

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

This is a Quality of Implementation issue.

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

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.  


> I probably could dream up some more cases, too.

Ever more extreme hypothetical cases do not interest me.

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

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.  

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

No.   You have been describing various ways that you believe that
a debugger might misinterpret the Dwarf 2 description of a program.
As mentioned above, you can misinterpret it, or not, as you wish.

> >
> > If you are done with these hypothetical situations, can we move on?
> >
> 
> This condescension is inappropriate.

Sorry you feel this way.  

Working with unrealistic and ever more fanciful hypothetical situations, 
like the ones presented in this email and the previous are at best tedious.


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