Re: Modifies vs. Replaces

[brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)]

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

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

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

>Perhaps this is a fine point, and I appreciate your concern.

Looks pretty blatant to me...

Ron