Some dwarf "nitpicks"

[Mark Wielaard <mjw at redhat dot com>]

Hi,

While hunting down some issues I had with dwarf_output on the examples
in the gdb testsuite I came across some "that doesn't look like valid
dwarf" things. Most of these were already discussed off list with Petr
to make sure dwarflint knows about them. But it seems better to have a
public archive of these issues, so others can help us interpret whether
or not they are really "invalid dwarf", just confusing, or something
else.

Silly usage note. If you are seeing lots of:
error: .rela.debug_info: offset 0x6: invalid relocation 10 (<INVALID
RELOC>).
you are probably running dwarflint against old elfutils libraries. Make
sure LD_LIBRARY_PATH is explicitly set to the freshly build libraries.

dwarflint would sometimes detect some low-level dwarf datastructure
corruption but then would run some of the high-level tests anyway. That
didn't end well, because dwarflint would crash on the bad data. Petr
already fixed this on the dwarf branch.

The gdb testsuite contains a lot of "minimal dwarf" examples (mostly
written by hand. There are some assumptions that might or might not be
valid. You can get some of these also with some minimal C "program".

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

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

These examples really don't have any .debug_line info, just an
short debug_line section header. Maybe gcc shouldn't output any header
at all, or maybe it should make the empty table by having only the
DW_LNE_end_sequence in it instead? Or should dwarflint ignore the table
if the header says the table is empty?

Attached are also some examples that show "bad child" marking in a dwarf
file. These can happen easily when you are writing dwarf examples by
hand (as is done in the gdb testsuite a lot). The diff of the .s files
will show that "accidentally" some DIEs were marked as not having
children but the "end of child list" markers are still there (it also
tweaks the siblings to be some other reference type, because dwarflint
does see the discrepancy in that case - go dwarflint! - except my
original didn't have sibling markers of course...).

The result is that something that relies on dwarf_siblingof will just
not see the last few DIEs. Since we are under the impression the CU is
done. This caused havoc for dwarf_output which was suddenly missing some
referenced DIEs. But you can also see that eu-readelf will just stop
early (interestingly binutils readelf will show them (but with an
indentation of zero, which is rather odd for non-CU dies).

I am hoping that since unit headers have a length and the "top-level" CU
die needs to have children that cover the whole unit dwarflint somehow
can detect that there is something odd going on with the children
relationship even if there are no sibling_AT markers. A zero or negative
"indentation level" for a DIE that isn't the top-level CU DIE should
probably cause at least a warning.

Cheers,

Mark

int
main (int argc, char **argv)
{
  struct foo { int bar; };
  struct foo *baz;
}

Attachment: hello-nested.s
Description: Text document

Attachment: hello-nested-missing-children.s
Description: Text document