Roland McGrath wrote:
> 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.
The OOo example was used simply to illustrate that dwarflint is
currently rough around edges. On closer look, that OOo file actually
does contain two consecutive NULL abbreviations at the end of non-last
section, which is excessive, dwarflint warns about it, therefore it's
not broken in this respect, and that's all there is to it.
What's extra/bogus is any content in the section that falls
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.
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.
dwarflint currently behaves as you describe. It flags all extra NULLs
except those that are used for alignment purposes. I'll just add the
extra check if alignment is required in the first place.