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).
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.