Re: DWARF version number

[Michael Eager <eager at eagercon dot com>]

Was this a response to a series of private messages?  I didn't receive any
of the quoted messages.  

Please attribute messages if they have not been sent to the Dwarf reflector.

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


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