Issue 150608.1: Value of DW_AT_dwo_id attribute
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
statement.
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.
Proposal
--------
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
something...
--
June 23, 2015 - Accepted
