Re: DWARF version number

[todd dot allen at ccur dot com (Todd Allen)]

> 
> >> 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