Re: Modifies vs. Replaces

[Michael Eager <eager at eagercon dot com>]

Jim Dehnert wrote:
> 
> And this is why you get the impression that we're talking about implementation.
> The current text is not adequate to unambiguously describe the situation where
> there are "holes" in the allocation of a variable to its home location (e.g.
> that specified by a global's defining instance's location info).  We keep
> talking about implementation to attempt to demonstrate the problem to you,
> since you show no signs of understanding it.  Now I assume that you do, in
> fact, understand, and either (a) don't care, (b) prefer to do nothing about
> it for some reason, or (c) think it's acceptable to have an ambiguous spec
> and leave it to each implementation to deal with the ambiguity via its own
> (unspecified) interpretation or extensions.  You haven't told us which, so
> we'll have to speculate until you do.  Several of us, however, believe
> this is a real, important problem in current compilers, and prefer to have
> an unambiguous Dwarf specification of how compilers can describe the situation.
> I for one don't care if we deal with some of the extended hypothethical
> optimization cases that have been described, but I do know of compilers
> that allocate memory variables temporarily (but for extended ranges) to
> registers, I think it's important to deal with this, and I think after our
> discussion that we know how (and it's not hard).

First, the discussion of "holes" leaves me unimpressed, because I see
no holes.  By "holes in the allocation of a variable to its home location",
I expect to find cases where this location is not valid.  In fact, the
only situation which has been presented is the very common situation that
a variable has multiple copies (usually two, the memory original and
a register copy), which may not all be coherent, but which are nevertheless 
all relevant to a debugger.

> To repeat, the fundamental reason the current specification won't deal
> correctly with reallocation of memory variables to memory is that it says
> that all locations in a list are equivalent.  So a producer has no standard
> way to tell the consumer which one to fetch a value from if there are multiple
> locations listed for a given address, so it must create a large set of disjoint
> location lists.  This was an efficiency issue in the case of our earlier
> discussion about default values.  It becomes a correctness issue if we allow
> locations with non-defining instances of globals to augment those of the
> defining instance, and expect the latter to have one all-inclusive range
> for the home location in static memory.  Perhaps you think there's a better
> way that avoids these problems.  If so, by all means describe it.

Let me assure you that I believe that I understand the problem you 
describe, but that I do not feel that it is a significant concern.
You claim that the specification says that all locations are equivalent,
but I don't believe that it does say this.  It says that objects exist
at multiple locations, but it does not make any statement about preference.
You may see this as saying that all are equivalent, but I believe that
this is a matter for interpretation by a debugger.

I believe that a reasonable debugger would see a non-defining declaration
for a variable in a register and conclude that this was the extremely
common situation where it should display the register contents and not
the global memory location, but that both should be modified.

I do not have a good understanding of other situations which do not
follow this model of a global copied into a register.  (Throughout 
this discussion I have attempted to elicit such an example, but none
has been forthcoming.)  I'm not at all sure I know what a reasonable 
debugger should do in this case, and I'm not comfortable with a 
prescription for how it should interpret a non-defining declaration 
which may foreclose on reasonable behavior.  Perhaps, as a first cut,
I'd display all values in all valid locations.  

There seems to be this undercurrent of assumption that a debugger 
(and debugger writers) are automatons, unable to distinguish different
situations and operate appropriately based on the circumstances.  I
don't share this view that a debugger (and debugger writer) must make
the most unreasonable interpretation or perform the most unreasonable 
possible action, so long as it is permitted within the specification.

> I think we can deal with this issue by extending your change slightly:
> 
> > If additional
> > text is desired, then perhaps a small change to the text of my proposal
> > would be reasonable (second paragraph under item 3):
> >
> > Change
> >         If the object is a non-defining declaration, the location
> >         specified modifies the location specified by the defining
> >         declaration and is only valid for the scope of the current
> >         declaration.
> > to
> >         If the object is a non-defining declaration, the location(s)
> >         specified provides additional location(s) for the object in
> >         addition to those specified by the defining declaration and
> >         is only valid for the scope of the current declaration.
> 
> --------- Only the first location listed from the non-defining declaration's
>           list for a particular address is guaranteed to contain the object's
>           value.  Copies in all locations, from both the non-defining and the
>           defining declaration, may be live.  (And must therefore be updated
>           if a consumer is updating, but that's a statement about consumers.)

Your text addresses the situation of a global value copied into
a register.  I think that it forecloses any other use or interpretation
which may be appropriate for other cases.  (I'm not sure that the text 
"may be live" could be described as unambiguous.)  

I think that your text (perhaps modified) is appropriate for the explanatory,
but non-constraining commentary:

	<italics>  This may be used to represent a local register copy of a 
	global variable.  In this case, the local copy may have a more current 
	value than the global's memory location.  If modified by a debugger,
	all copies would usually be modified. </intalics>

> I would prefer, incidently, to make the same statement about simple location
> lists that aren't unions of defining and non-defining instances, because it
> would solve the same problem in that case without requiring full lists for
> disjoint ranges.

I have no problem with suggestions on how various features of Dwarf 2
should be used.  

I am sure that reasonable compilers will generate location information
which is exactly as you and I expect, and that reasonable debuggers 
will interpret it exactly as we both think is correct.  By not specifying
every detail of how we believe a reasonable compiler and debugger should
operate, we perhaps permit compiler and debugger writers to do unreasonable
or even silly things and still be in conformance with the standard.  This
same flexibility (or ability, if you prefer) allows the feature to be
used in ways that we cannot now predict.

Philosophy:  In general, Dwarf 2 permits producers to generate whatever
they wish, with only limited restrictions.  For example, the spec provides
some guidance on the attributes which may commonly be used with particular
TAGs, but it does not prevent a producer from using others to describe 
programs.  In many cases, this has permitted developers to use Dwarf 2 
to describe program features which had not been previously considered or
known.  Some of these extensions have been adopted in our current
revisions.  I believe that this flexibility is valuable, even if it
does permit a degree of ambiguity.

There is a difference between the Dwarf 2 specification, which is 
permissive, and a language specification, which is restrictive.  In the
latter, any program which conforms to the specification is considered
to be valid and should have a consistent interpretation.  In Dwarf, 
the specification permits a larger domain of program descriptions,
which encompass both reasonable and unreasonable descriptions.  
 

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