Re: Status 2009-01-19

[Petr Machata <pmachata at redhat dot com>]

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

Great.  What you write about above is already done (modulo reloc).

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

Makes sense, I'll do that.

PM

Attachment: signature.asc
Description: PGP signature