Re: Status 2009-01-19

[Roland McGrath <roland at redhat dot com>]

>        * Validation and coverage analysis of .debug_loc.  For some 
> reason this consistently yields a lot of holes.  [...]

Just post some examples.  We might be able to tease it out quickly between us.  

>     * Finish what's left of .debug_aranges work (address/length 
> validation, .text coverage).  

That's a high-level check, don't do that in the structural checks.  Just
check the basic format so dwarf_getaranges won't be confused, and the
connectivity check that the CU header offset is to some proper CU header
(plus reloc checks).  The correctness of the addresses will be done in a
high-level check that will be trivial in C++ (when those interfaces are done).

> Finish what's left of .debug_loc (i.e. 
> look at the coverage problem above).

The .debug_loc writing/rewriting is one of the last things we'll get to.
So any time sink in this work should just be put off til later.  Don't
put time into any fancy measures to figure it out right now.

>     * Write .debug_ranges validation.

This too needs only structural checks and reloc checks.

Another thing about the messages: "CU 0x234 DIE 0x123" is nice, but not
quite as handy as it could be.  eu-readelf identifies DIEs in hex with
the absolute section offset, not the offset from the CU.  It identifies
CUs with "at offset %u".  The dwarflint messages are pretty long
already.  So I think just "DIE 0x345" is sufficient, and use the section
offset (a la dwarf_dieoffset) so that you can grep for the hex in
eu-readelf output and find it easily.


Thanks,
Roland