Re: DWARF version number

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

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

   Your point about DW_AT_producer is a good idea.  We certainly could use
   that as a better differentiator between our DWARF2.0+OldConcurrentMods and
   DWARF2.1+NewConcurrentMods than adding a new attribute.

   We didn't feel terribly guilty about subtly changing the meanings of
   preexisting attributes when they were attached to debug entries with tags
   that we invented.  No non-Concurrent consumer would get far enough even to
   try interpreting them.  We also didn't feel too bad about changing the
   meanings of attributes when we were allowing new forms that DWARF 2.0
   didn't allow for them (e.g. DW_FORM_block location descriptions for
   DW_AT_upper_bound).  Now, this seemingly innocuous change conflicts with
   DWARF 2.1.  So, it's possible that we went too far and changed the
   meanings of some attributes that we shouldn't have.

   Having said that, there's nothing we can do about it now.  It's done.  Are
   we alone in this respect?  Did any other company's producers make subtle
   changes to any preexisting attributes that could break any other company's
   consumers?  If not, and there's no other compelling reason to change the
   version number, then probably our situation shouldn't burden any other
   companies.

   As I said, if there's a consensus that the version number shouldn't
   change, then we'll deal with it ourselves.  Probably with the
   DW_AT_producer, as Dave suggests.

-- 
Todd Allen
Concurrent Computer Corporation