This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: Modifies vs. Replaces
- To: Ron 603-884-2088 <brender at gemevn dot zko dot dec dot com>
- Subject: Re: Modifies vs. Replaces
- From: Michael Eager <eager at eagercon dot com>
- Date: Sat, 24 Mar 2001 00:57:12 -0800
- CC: todd dot allen at ccur dot com, DWARF2 at corp dot sgi dot com
- References: <01032316594094@gemevn.zko.dec.com>
- Reply-To: Michael Eager <eager at eagercon dot com>
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