This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dwarflint


> The DWARF documentation allows sequence of NULL abbrevs at the end of 
> the last abbrev section, for alignment purposes on certain platforms 
> (that's approximate wording, I don't have the standard before me).

Right.

> What that OOo debuginfo file contains is technically empty abbrev 
> section, i.e. a sequence of two consecutive NULL abbrevs.  So to the 
> parsing algorithm it looks like we ran into the terminating NULL 
> sequence, and it's unhappy when non-NULL abbrevs suddenly pop up.

I'm not sure I follow this.  The .debug_abbrev section concatenates
uncoordinated portions for different CUs.  Each CU claims the portion
from the offset in that (.debug_info) CU header through the first 0
abbrev record thereafter.  

What's extra/bogus is any content in the section that falls outside
all such ranges (similar to unused parts of a string table).  What's
acceptable padding is stretches of that extra content that are all 0.
Any such padding is unnecessary, worthy of some enableable warning.

> Currently dwarflint tolerates the NULL sequence, if it rounds the 
> reading pointer up to the alignment of the ELF .debug_abbrev section. 
> (Hmm, and I just realized it doesn't check if it's possible to achieve 
> that alignment with fewer NULL abbrevs.)

If .debug_abbrev has sh_addralign > 1, then you can skip the
individual warnings for places there is 0 padding if the offset at the
end of the padding is aligned to sh_addralign.  This can have a
separate (single) warning that .debug_abbrev has sh_addralign > 1,
which it never really needs.


Thanks,
Roland

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]