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