Some dwarf "nitpicks"

Petr Machata pmachata at redhat.com
Mon Mar 7 15:39:19 UTC 2011


Mark Wielaard <mjw at redhat.com> writes:

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

In your case, the DIEs that would normally be children became siblings
of the CU DIE.  But the dwarf standard prescribes that each CU contain
one CU DIE and its children, so this setup is invalid.  dwarflint should
have diagnosed this case, and this is now fixed on the dwarf branch.

Thanks,
PM


More information about the elfutils-devel mailing list