On Mon, 2011-03-07 at 09:56 -0800, Roland McGrath wrote:
$ echo > empty.c $ gcc -g -c empty.c $ dwarflint empty.o error: .debug_abbrev: couldn't load CU headers; assuming CUs are of latest DWARF flavor. error: .debug_abbrev: no abbreviations. error: .debug_info: data not found.
This produces zero-length .debug_info and .debug_line sections. There is nothing wrong with that, though it would of course also be fine if it didn't emit the ".section" directives at all.
It produces a .debug_abbrev section that is nothing but a single 0 byte. That is superfluous and it would be better if it omitted it entirely, so I would recommend reporting that as a GCC bug. (Many such files will add up to lots of wasted zero bytes in the linked output.)
Bug and proposed patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48041
$ echo "static int empty;" > empty.c $ gcc -g -c empty.c $ eu-dwarflint empty.o error: .debug_line: table 0: sequence of opcodes not terminated with DW_LNE_end_sequence.
This produces a zero-length .debug_line section but a CU with a DW_AT_stmt_list attribute pointing to its start. That is invalid DWARF and hence a GCC bug. The place where DW_AT_stmt_list points must have a valid line information header, even if that says it's an empty table. I think what would be most correct here is to omit the DW_AT_stmt_list attribute entirely from that CU DIE.
Actually, the header is there, but there are no tables. Reported with possible patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48045
But since the debug_line table header is actually there, dwarflint is still not really happy. empty.o as produced by my patched gcc attached.
$ eu-dwarflint empty.o warning: .debug_line: table 0: the file #1 `empty.c' is not used. error: .debug_line: table 0: sequence of opcodes not terminated with DW_LNE_end_sequence.
So maybe a better solution would be to just add a dummy end_sequence.
Cheers,
Mark