dwarflint

[Roland McGrath <roland at redhat dot com>]

>    * Expected time spent on elfutils: 80%

Woo!  Happy New Year!

>    * Push dwarflint commit that I've done last week (I was offline so 
> couldn't do it right away, it slipped my mind today).

I'll try to review the new code this week, but don't let me slow you down.

Please edit DwarfTasks with your specific items/milestones for upcoming
dwarflint work.  You can also edit DwarfLint with any details or status
updates as you like.  (I'm trying to encourage everyone to put a lot of
info on the wiki.  It seems like the best way--along with just producing
good code ourselves, of course--to facilitate any new contributors getting
involved with the project,)

>    * See how dwarflint does on the test suite that Roland posted about.

If you have a spare local machine with plenty of disk (and local rawhide
mirror), great.  It takes a day or so (a night, at least) to unpack the
data.  I have it set on a spare test machine at home now.  So any time you
think something is ready for testing, I can do a run.  In fact, I'll just
start one now for dwarflint.

>    * Checks for correct DW_AT_sibling attribute value

The hard correctness check is that it's DW_FORM_ref* and that the ref
offset value matches the physical sibling's offset.  Warning checks:

* uses DW_FORM_ref_addr (technically kosher but quite suspicious)
* a !has_children DIE has DW_AT_sibling (superfluous)
* a has_children DIE has no DW_AT_sibling (suboptimal)

>    * Checks for other sections (aranges, ranges, locs)

.debug_pubnames is also pretty simple.  These are in two classes, nicely
illustrated by Figure 43 on page 194 (the one labelled "Page 182") of
Dwarf3.pdf.  aranges and pubnames (and pubtypes, though our gcc isn't
actually generating it) point to CUs.  All the others are pointed to by DIE
attributes of a particular class.

I would do the former (aranges, pubnames) first.  These are self-contained
and point to CU headers (and DIE offsets), so you can check them
completely.  Nothing else depends on this data, so while there are
non-warning hard errors that will always be fatal, even those should never
terminate dwarflint.  We can still do all the other checks, and just not do
any of the high-level checks that are particular to these sections.  (These
are just fast-lookup tables, and technically they are entirely optional
optimization and not the "normative" data.)

For the others you can do structural checks for now.  The connectivity
checks depends on knowing which attributes have the pointers, which I'd
like to do in a general way along with the C++ attr values support.
(i.e. not this week.)


Thanks,
Roland