Issue 150608.1: Value of DW_AT_dwo_id attribute

Author: Ron Brender
Champion: Ron Brender
Date submitted: 2015-06-08
Date revised:
Date closed:
Type: Error
Status: Accepted
DWARF Version: 5
Section 3.1.2 & 7.3.2, pg 59 & 175
Skeleton compilation units (S3.1.2)and split DWARF object files
(S7.3.2) both have a DW_AT_dwo_id attribute who value is a hash 
that must match to confirm a correct pairing. This hash is 
defined in the May 16, 2015 draft, page 59, as follows:

   "This hash value is computed by the method described in
   Section 7.32 on page 227."
Unfortunately, there are major substantive problems with this 

Problem Summary

Section 7.32 is all about how to compute a type signature,
not a compilation unit signature. Moreover the types that
can be handled, and therefore need a signature, are restricted
to those types that have no associated code and no references
to DIEs other than types. Table 7.31 reflects this in part by 
significantly limiting the attributes that can be encoded.

Trying to use this section as a basis for a unit signature will
at best involve significant editorial rework. At worst, it is
likely impossible. But, quite honestly, I don't see that this 
is either necessary or desirable.

Problem Resolution

Recall that the one and only purpose of a unit signature is
to assure that a consumer has a skeleton compilation unit
and a split DWARF object file that go together. The two
must be created by the same producer at the same time as
part of the same compilation. To achieve this, the producer
puts a "signature" in both parts to guard against an accidental
mismatch by a consumer

The only thing a consumer needs to do with this signature
is to compare two instances for equality. If they don't
match, the pair is useless and must be recreated.

This leads to the suggestion that this "signature" can be
left totally implementation-defined. In fact, a truly random
number from a large domain (say 64 or 128 bits) will work
just fine.


1) Replace bullet 5 in S3.1.2 with:

   A DW_AT_dwo_id attribute whose implementation-defined
   integer constant value
   provides unique identification of this compilation unit
   as well as the associated compilation unit in the
   split DWARF object file named in the DW_AT_dwo_name
   attribute. For simplicity, the skeleton compilation
   unit and the split DWARF object file must use the same
   form to encode this identification value.

2) In Section 7.3.2, page 175, split the first bullet
   of the second group (5th bullet on the page) into
   three bullets as follows:
   . The full compilation unit, in the .debug_info.dwo section.
     This entry includes a DW_AT_dwo_id attribute whose form
     and value is identical to that in the DW_AT_dwo_id attribute
     of the associated skeleton compilation unit.
   . Attributes in debugging information entries may refer to
     machine addresses indirectly using the DW_FORM_addrx form
     which accesses the table of addresses table of addresses
     given by the DW_AT_addr_base attribute in the skeleton
     compilation unit. Location expressions may similarly do
     so using the DW_OP_addrx and DW_OP_constx operations.
   . DW_AT_range attributes may refer to range table entries using 
     the DW_FORM_base_offset form which accesses the ranges table
     given by the DW_AT_ranges_base attribute in the skeleton 
     compilation unit.

Note: the third bullet assumes acceptance of my separate proposal
to add form DW_FORM_base_offset. The rest of the proposal stands
even without this new form.

3) I suppose something could be added in Appendix F regarding
this unit identification, but I don't think it necessary. But
I am open to suggestions if someone (Cary?) wants to offer

June 23, 2015 - Accepted