This is the mail archive of the dwarf2@corp.sgi.com mailing list for the dwarf2 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Modifies vs. Replaces


Ron 603-884-2088 wrote:
> 
> Todd Allen, quoting Michael Eager, wrote:
> 
> >> To make my point succinctly, describing such a location description
> >> as modifying the location description on a defining declaration
> >> permits a debugger to decide how this modification is to be done.
> >>
> >> My opinion is that in most (perhaps all) cases, augmenting the
> >> location information of the defining declaration would be the
> >> appropriate action for a debugger to take.  Todd, on the other hand,
> >> would decide that the appropriate modification is to replace the
> >> defining declaration's location information with the non-defining
> >> location.
> >>
> >> In either case, this represents a modification to the location
> >> information as described in the proposal.  As far as I can tell,
> >> the proposal, as written, permits a debugger to act both as I
> >> would feel is correct and as Todd would have it act.
> >>
> >> Todd has suggested that the non-defining location information
> >> must replace the location information of the defining declaration.
> >> This would eliminate the interpretation that the two sets of
> >> information were to be merged and require me to make the same
> >> design decisions in my debugger that he wishes to make in his.
> >>
> >> Modifies permits a range of reasonable interpretations, which
> >> include replacement.  The converse is not true.
> >>
> >
> >I think it is unwise to leave the interpretation of this to the debugger.  As
> >you like to point out, DWARF2 is intended to describe the structure of the
> >program.  Leaving this ambiguous in the standard leaves the definition of the
> >structure ambiguous.  If a compiler and debugger resolve the ambiguity in
> >different ways, they won't interoperate well.  I should think one of the
> >goals of the standard would be to define the description clearly enough that
> >compilers and debuggers can interoperate well.
> 
> The discussion over "modifies" vs "replaces" has been very hard to
> follow -- both terms, and especially "modifies", are pretty generic in
> common English usage. Quite honestly, when I first read the original
> proposal of 22 March, I thought that "modifies" was in fact intended to
> mean what Todd later came to call "replaces" -- but especially, it never
> occurred to me that it was intentionally ambiguous!
> 
> Please, folks -- it is hard enough to be unambiguous even when we try,
> lets not deliberately slip in a little intentional ambiguity without
> warning! At the very least, if we want to allow alternative interpretations
> then we need to say this clearly; maybe even present two or three to
> illustrate the differences. There are places where we accept it as a
> fact of life (for example, what character set is used for names in
> the absence of DW_AT_use_UTF8?), but at least we are clear that the
> "meaning" is undefined by DWARF and subject to implementer choice.
> 
> Moreover, I have yet to hear any argument that such ambiguity is actually
> goodness in this case. It is actually becoming reasonably possible to
> have a choice of several debuggers (system vendor's, gdb, TotalView, ?)
> to use on the same executable -- why would we want to allow a variety of
> interpretations among debuggers for the same DWARF? I can't think of
> any plausible reason...

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.  

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.

I see no ambiguity in the Dwarf description.  My intent was to
point out the range of possible behaviors which a debugger can take.  

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]