Re: dwarflint

[Roland McGrath <roland at redhat dot com>]

I built dwarflint rev 17efac5.  Zillions of files had the same message:

abbrev 0x1: abbrev with non-zero code follows several abbrevs with zero code.

Some even had a different offset. ;-)

	gcc -xc -g -c /dev/null -o empty.o

produces a .debug_abbrev of size 1, containing a 0 byte,
and .debug_info and .debug_line of size 0.

I'm not sure why this comes up so often, since the common things like
crt1.o don't have .debug_*.  I guess maybe it's files whose contents are
all inside #ifdef for something configured out, or something like that.
But anyway, when a .o file like this gets linked in with others, there will
be some unused padding in .debug_abbrev.  It seems to be very common as the
first file for some reason, but also can happen in the middle.

Clearly this is in the "bloat" category, but also "known gcc bloat"--when
it's just unnecessary padding.  I find the message less than enlightening
for what this case is.  It's some padding not needed for any purpose (no
alignment is required for .debug_abbrev anyway, and even if it were, 0 is
pretty well aligned), but it's zero bytes, so not "suspicious bloat".

Since abbrevs are only read following a pointer in a CU header, the real
abbrev section at 0x1 doesn't "follow zero abbrevs", it appears after an
unused part of the section at [0,1).  It's no different from a string table
with excess zero bytes between referenced entries, etc.


Thanks,
Roland