Re: DWARF version number

[David Weatherford <David dot Weatherford at Sun dot COM>]

Let me throw in my $0.02 worth.  When a compiler changes the way
that it encodes information by adding a vendor-extension tag or
attribute, that is not a DWARF version number change -- the DWARF
format has not changed, only the usage.  This type of change should
be reflected in the DW_AT_producer attribute of the compilation unit.
That should be a string that uniquely identifies the compiler, its
externally visible version number, AND some kind of "DWARF usage
version number," which is unrelated to the 2-byte version number
in the compilation unit header (currently "2").  This allows a
debugger familiar with that compiler and its various extensions to
determine the proper semantics to associate with those extensions,
even in the face of changing specifications for a given vendor
extension.

I would argue that changing the meaning of existing DWARF attributes
is probably prohibited by the DWARF spec (or should be), as consumers
which do not know about your non-standard usage would be broken by
the change, unlike adding vendor extensions, where non-aware consumers
are deficient, but not incorrect.

In any case, only changes which are upwardly incompatible with 2.0
should cause the DWARF version number to change.  I define "upwardly
incompatible" as "causing a 2.0-conforming consumer to display
incorrect information."

Dave W.

Todd Allen wrote:
> 
> >
> > >> So the conclusion is, I think: if a producer has done something outside of
> > >> the DWARF2 design in order to compensate for some limitation of DWARF2, then
> > >> it may find it cannot switch to doing things the "new" (I'll not say "right")
> > >> way without harming its users of old consumers. This is obviously true to my
> > >> mind.
> > >
> > >This is an assumption on your part that something incorrect was done to
> > >compensate for limitations in Dwarf 2.  I don't believe that this is either
> > >a warranted or useful assumption.
> >
> > I am not assuming anything incorrect. Extension is valid in DWARF. My
> > observation is that if a producer withdrawns its own extensions in favor
> > of using the new V2.1 mechanisms, then a user of a V2 consumer that knows
> > about the earlier extensions is likely to feel some lose of capability.
> > That is all I intended to say.
> >
> 
> I've completely lost track of who said what in this argument.  I'll just
> throw in my 2c worth, which is related to the above comments.
> 
> Especially with Ada, but even with C++, there were several language features
> that weren't supported in DWARF 2.0.  Because DWARF 2.0 provided no direction
> for those features, but allowed us to extend it, we did.  For instance, we
> describe namespaces, but in a manner unlike the one you selected for the
> DWARF 2.1 spec.
> 
> Because we were rolling our own spec, so to speak, we figured it would be
> incompatible with others' implementations.  So, we loaded a certain amount of
> knowledge directly into the debugger, in an effort to keep the DWARF small.
> For instance, our debugger knows that, to obtain the addresses of certain
> pieces of information that it needs, it has to concatenate two location
> descriptions together.
> 
> In retrospect, that's unfortunate.  (And I won't say "wrong", either.)
> Because now there are newer & better ways to accomplish the same thing
> (e.g. DW_OP_call*).  Still, we have to convince our debugger to stop behaving
> the way it always has, and starting doing things the New Way.  And all the
> while still supporting programs that were built with compilers that did it
> the Old Way.
> 
> This is why I think some indication that this is Dwarf 2.1 and not Dwarf 2.0
> is a good thing.  However that indication is made.  Changing the version
> number in the header seems the easiest solution.
> 
> If the group decides not to change the version number, then we'll just have
> to add some other vendor extension to indicate that we're producing Dwarf 2.1
> to our debugger.  Probably, it will be a new attribute on each
> DW_TAG_compile_unit entry.  But I'd rather not have to do that.
> 
> --
> Todd Allen
> Concurrent Computer Corporation

-- 
Dave Weatherford                Forte Tools
David.Weatherford@Sun.COM       Sun Microsystems, Inc.