Re: DWARF version number

[Michael Eager <eager at eagercon dot com>]

David Weatherford wrote:
> 
> 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 think that there is nothing in the Dwarf 2 standard which says
that the DW_AT_producer attribute should be used in this way.  
I know of no debuggers which act the way you say they should.  The
very purpose of having a well defined standard with a version number 
is to avoid the chaos that your suggestion produces.

This would require a consumer to have a list of the various compilers
which it supports, including the versions of the compilers, so that
it can verify that it knows that it can support Acme C 2. and Bigcorp
C++ 3.5.  But what should a consumer do when it gets Acme C 3.1 or 
Bigcorp C++ 3.7?  Complain that it doesn't know these compilers?
Should it reject Dwarf from the Colossus 1.1 compiler, because it
was created after the consumer was written?  Even if the Dwarf it 
generates is identical to the Acme compiler?

This is the way COFF (the misnamed Common Object File Format) works.
It's common, but there is a different format for Intel 386 and Intel
960, not to mention the modified versions for NT or AIX.  There is
no version number: every version of COFF is similar but different.  

The purpose (or at least one purpose) of the DW_AT_producer attribute 
is that when you identify an error in the Dwarf generated by a 
compiler, you know which compiler to look at.  The purpose of the
version number is to identify the Dwarf standard used to generate
the data so that the consumer can determine if it is compatible
without having to know all past and future producers.

You place the burden on past debuggers, requiring that their creators
anticipate what future unknown compiler writers might or might not
do.  I believe that this burden for compatibility should be born by
the producer.

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

I think that this same principle should extend to changes in the way
the structure of a program is represented.  If a feature which was 
represented in one fashion in Dwarf 2 is now represented by new and
different attributes, then the existing consumer would be just as
confused and unable to interpret the information.
 
> 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."

Here we have agreement.  If the Dwarf generated by a new producer looks
the same as a Dwarf 2 producer (possibly modulo what appear to be 
extensions) then it is reasonable to identify it as Dwarf 2.0.

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