Re: Modifies vs. Replaces

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

David Weatherford wrote:
>Mike was saying that the DWARF document describes a format which may
>be used by DWARF producers (typically compilers) to communicate certain
>aspects of the structure of some piece of a program to any interested
>comsumers (typically debuggers).  As such, the spec describes logical
>contents and physical file format for several "sections" (typically
>ELF file sections) along with certain conventions for using the tags
>and attributes defined by the spec.  It does *not* contain a set of
>rules that a producer must follow given a certain input.  That would
>be the job of a language bindings document for a given language, none
>of which has been written (to date), as far as I know.
>
>Now, we all have in our heads typical (?) language bindings for the
>languages that we are most familiar with, and we each try to make the
>DWARF spec sufficiently flexible to support those bindings efficiently.
>This is good.  But those bindings are not part of the spec.  The spec
>describes mechanism, and has only a few italicized hints concerning
>policy (i.e., bindings).  Thus it is descriptive, but not proscriptive.

I absolutely agree.

Michael Eager wrote:
>Dwarf provides a structure for representing programs.  We permit
>people to use as much or as little of this structure as they see
>fit.  Our only "demand" is that when a producer uses a certain
>part of Dwarf, that they use it as described in the specification.

Again I agree.

But, I am mystified as to how the conversation turned to bindings rather
than interpretation of particular descriptions. My focus is trying to be
on what does it mean when a non-defining declaration has a location
attribute.

>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 work 'appended'
>rather than modifies.

I did suggest that "modifies" in particular is far too generic a term;
yes, "appended" seems far better at capturing the meaning that you [now]
appear to be advocating.

But then, I don't understand this:

>What you describe as an ambiguity is my pointing out that the
>debugger can choose 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.

Those words sound to me like you are suggesting that a debugger can
correctly, that is, act consistently with the DWARF interpretation, by
choosing any of the three actions. But (I am relieved to hear) you now
seem to be saying that we (the DWARF committee) can choose which among
those reflects the actual meaning--and that you advocate/recommend #2.
In which case, a debugger has no choices--if it is to act consistently
with the specified DWARF meaning. (It *has* to "choose" #2 as well!)

Finally, "#3 is current behavior." is what (mis)lead me to commenting
on "current" (ie V2) debuggers. There are no V2.1 debuggers to have
any current behavior so I thought you must be saying something about
exiting V2 debuggers...

Okay, enough about ambiguity. Whether or not #3 is current behavior
in any sense aside, #3 really a is non-useful alternative so the real
choice comes down #1 vs #2. It now appears that:

  - You favor #2
  - Todd and I favor #1

And debuggers have only one choice: to act consistently with what
the committee chooses as "the" DWARF interpretation, or not.