Issue 041108.1: Is Extra Padding Allowed
See Draft 8 dwarf3 sec 7.19.
The Name Lookup Table has
unit_length
giving the net length of the entries for a CU.
The Tuple set describes how a final offset-of-0
defines the end of the Tuple set.
Question: Is it legal for a compiler to emit a
unit_length which 'goes past' the end of the final offset-of-0.
(ie, which counts some padding-bytes at the end)
In other words, is it legal for a compiler to have padding
bytes at the end of the Name Lookup Table for a CU?
Apparently
armcc ARM C Compiler , ADS 1.2 [Build 805]
does have such padding. Is it legal dwarf2/3?
I cannot find anything forbidding such padding.
Ron Bender writes:
I agree the DWARF spec is not clear in this regard.
Moreover, it appears that such an inflated length is quite
benign.
I suppose the same answer should apply to .debug_aranges.
Also .debug_info, which explicitly allows zero padding.
I think it also "works" OK for .debug_line?
Chris Quenelle writes:
I had a similar problem. For us, the padding was
inserted by the linker in between blocks generated
by the compiler. I think the wording in the standard
is pretty clear. Exactly one zero entry should be included
in the length.
Unfortunately this is redundant information.
There seem to be several places where the boundary
of a data block is described by both a length and
a terminating entry.
It is left up to the implementation to decide what
to do when the two pieces of information conflict with
each other.
To deal with our linker padding problem, I had to
teach libdwarf to accept a zero value for
the initial length, and skip over that looking for
the next block.
I also had to pad the .debug_info blocks generated
by the compiler so they were all a multiple for 4 bytes.
This was needed to guarantee that the padding was always
in units of 4 bytes so that they could be skipped.
In answer to your question, it seems like a good idea
to extend the definition of Name Tables so that
any number of zero offsets can occur at the end
of the block (within the bounds defined by the
inital length field).
==============================
Closed: It was felt that the standard is clear.
