Re: dwarflint

[Petr Machata <pmachata at redhat dot com>]

Roland McGrath wrote:
>>    * 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.

Great, thanks.  I'll set up the environment on the office machine, 
there's a fedora mirror ten meters away, so at least the downloading 
itself will be snappy.

>>    * 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)

The above is on the branch, I've done it earlier today.

> * a has_children DIE has no DW_AT_sibling (suboptimal)

This didn't cross my mind.  I've put the check in, and it seems to be 
quite a common case: 14K violations in that hefty OOo library, and 850 
violations in libX11.so.  Do we really want to flag this?  Maybe make it 
a strict warning only?

Speaking of which: I never know what should be strict and what should be 
warning.  Warning/error is easy: warnings are for suspicious constructs, 
errors for outright standard violations.  Now enter strict.  Why are 
strict checks strict?  Are these even more anal checks?  In that case, 
do strict errors make sense at all?

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

Ok, I'll work on this next.

> 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,
PM

Attachment: signature.asc
Description: PGP signature