Roland McGrath wrote:
> Sorry, that should have been a "NULL abbrev," an abbrev
with code 0,
> used for alignment purposes. The open office library contains sequences
> of non-NULL abbrevs. These technically form empty abbreviation
> sections, so maybe make it a warning instead?
Did you mean that it contains NULL abbrevs? There are no authentic
alignment requirements in .debug_abbrev either, so this can be treated
similarly to the string table padding.
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.
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.)