On Wed, Jan 04, 2017 at 01:58:33PM +0100, Mark Wielaard wrote:
> On Wed, Jan 04, 2017 at 12:09:43AM +0100, Jakub Jelinek wrote:
> > http://dwarfstd.org/ShowIssue.php?issue=161031.2
> > got approved today, so DWARF5 is changing and the various DW_UT_* kinds
> > will no longer have the same size of the headers. So,
> > DW_UT_compile/DW_UT_partial shrinks by 12/16 bytes (padding 1 and padding 2
> > is removed; 16 bytes for 64-bit DWARF), DW_UT_type remains the same,
> > DW_UT_skeleton/DW_UT_split_compile shrink by 4/8 bytes (padding 2 is
> > removed). For DW_UT_* kinds consumers don't understand, the first 3 fields
> > (length, version and ut kind) are required to be present and the only
> > sensible action is to skip the whole unit (using length field).
>
> OK, so I assume my alternative proposal to encode which fields are
> used in the unit type field got rejected?
> http://dwarfstd.org/ShowIssue.php?issue=161130.5
> (Any word on other proposals? They don't seem to have been updated
> on the website yet.)
It will take a while before the web is updated and the changes actually
materialize in the document.
Yes, 161130.5 has been rejected.
As for other proposals, not sure if I remember all the details, I think
160808.1 is in, 161027.1 will say that the hashing of identifiers in
.debug_names (no matter if case sensitive or not) roughly starts by
replacing U+0131 characters with U+0069 (i.e. use i instead of small
dotless i), then applying C + S case folding from Unicode 9.0's
CaseFolding.txt and then hashing the resulting string as described in the
public draft. At least that is my understanding. 161031.2 accepted,
161031.4 deferred, 161102.1 accepted, 161230.1 accepted, 161122.1
I think we are going to have DW_FORM_strx{1,2,3,4} or something similar
in addition to DW_FORM_strx (i.e. fixes size 1, 2, 3, 4 byte indexes
into .debug_addr), 161130.2 rejected (DW_AT_type should be used instead),
161130.3 rejected, 161206.[123] need more thinking, 161215.[12] rejected,
don't remember others.
> Was anything said about what consumers should do when the version is
> unknown? Is the length field still valid and can the unit be skipped
> or is it game over?
See above, I tried to explain it. All the units have to have the
unit_length (initial length)
version (uhalf)
unit_type (ubyte)
fields at the beginning of their headers in that order (otherwise you
couldn't even find out what the unit type is), the rest is well defined
only for the unit types documented in the spec.
So, for other unit types (unless they know how to handle them), consumers
should just skip over it (i.e. advance by unit_length from the start of
the version field.
> Is any of the range of unit type values reserved for vendor extensions?
Yes, DW_UT_lo_user ... DW_UT_hi_user.
Jakub
