This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: dwarflint
- From: Roland McGrath <roland at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 16 Dec 2008 15:15:32 -0800
- Subject: 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