Re: Modifies vs. Replaces

[Michael Eager <eager at eagercon dot com>]

Ron 603-884-2088 wrote:
> 
> Michael Eager wrote:
> >The Dwarf spec doesn't specify what a compiler should generate, nor
> >does it specify what a debugger should do with the data generated.
> >We continually leave the job of determining what action to take
> >given a specific Dwarf description to the debugger.
> 
> Wow, these assertions leave me incredulous. Our job is to specify
> what descriptions mean. Surely we expect that a compiler will generate
> a description whose interpretation/meaning is consistent with the
> program and how it was compiled. And surely we expect that a debugger
> will take actions that are consistent with the specified interpretation
> of the description it encounters. While we don't specify "actions"
> as such, actions that are inconsistent with the DWARF specified
> interpretations are bugs...

There have been several suggestions over many years that someone
would write language bindings.  No one has so far.  There are different
descriptions for programs which conform to the Dwarf specification.

It's a matter of opinion about what a compiler should do and what
actions a debugger should take that are consistent with the
specified interpretation.    Many of your arguments for one proposal
or another have been based on what you believe correct operation
or behavior of a debugger should be, rather than whether the Dwarf 
correctly describes a program.  It has frequently appeared to me
that you have the cart before the horse -- attempting to specify
the behavior of the debugger, rather than the description of the
program.

 
> >What you describe as an ambiguity is my pointing out that the
> >debugger can chose to take any of several actions when presented
> >with a non-defining entry with location information:
> >
> >  1) Ignore location information in the defining entry, and
> >     only use the location information provided in the non-defining
> >     entry.
> >  2) Treat the location information provided in both entries as
> >     valid, describing a variable with multiple locations.
> >  3) Use only location information in the defining entry.
> >
> >#3 is current behavior.  #2 is what I would recommend.  #1 is
> >Todd's preference.  You may find one or more of these to be better
> >implementation choices than the others, or perhaps you have
> >another behavior.
> 
> In what sense is #3 "current behavior"? DWARF V2, Section 4.1, bullet 3 says
> in part:
> 
>     A data object entry representing a non-defining declaration of the
>     object will not have a location attribute...

Since there is no location information in the non-defining declaration, 
behavior of debuggers must only be using location information in 
the defining entry.  As indicated above in #3.

> Since a location attribute is not supposed to be there, the interpretation
> of that attribute in this case is not specified by DWARF. I would expect
> that the most likely "current behavior" is indeed for a debugger to ignore
> the location attribute--not because DWARF specifies the location
> specified of the definition declaration takes precedence, but because
> DWARF specifies that that representation should not happen; so a prudent
> debugger will likely ignore that unexpected and undefined representation,
> perhaps warn the user of an invalid DWARF description, and proceed as best
> it can. In this case a fourth action missing from your list might well be
> 
>     4) Refuse to process the erroneous DWARF description (including
>        the complete containing compilation unit)

This is perhaps the behavior of a debugger which doesn't support the 
proposal, but not one which does.

I find this confusing:  my comments were directed at how a debugger
which implements my proposal might work.  Your comments are about
how a debugger which doesn't support the proposal might operate.  I'm
not at all sure that apples and oranges discussions are fruitful
(pardon the pun).

> >I see no ambiguity in the Dwarf description.  My intent was to
> >point out the range of possible behaviors which a debugger can take.
> 
> Are you referring to the V2 Dwarf description or the Dwarf description
> that would result from your proposal?
> 
>   - As I indicated above, V2 is not ambiguous. It is quite clear that
>     the representation at issue "will not" happen.
> 
>   - If your proposal intends to specify for Dwarf V2.1 that the meaning
>     of a location attribute on a non-defining declaration can be any of
>     the three alternates you suggest, at the option of the generator
>     without means for the consumer to figure out which, then
> 
>       . It is surely possible to say this unambiguously, but your
>         suggested wording does not do so.
> 
>       . The result is not very useful because it cripples the additional
>         descriptive capability we are trying to add. Indeed, I would
>         then oppose the proposal on that grounds.

I haven't proposed any alternate meanings.  (I seem to be repeating
myself.)

My proposal says what it intends to say.  The location information 
in a non-defining declaration modifies the location information in 
the defining declaration.  Perhaps you would prefer the word 'appended' 
rather than modifies.

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