Re: sequential reading of .debug_loc

[Petr Machata <pmachata at redhat dot com>]

Roland McGrath wrote:
>> In the mean time, I switched back to the old way of validation, but I'm 
>> attaching the patch (formed against 8aef81) in case anyone wants to see 
>> on their own eyes.
> 
> Yeah, I think the way to handle this and all the CU-derived (*ptr attr)
> sections like .debug_ranges is to only fully validate the chunks that some
> *ptr attr points to.  You don't need to check those at all until after the
> structural checks on .debug_info pass, so you can have the full
> connectivity info on hand.

One thing that the connectivity will be useful for is checking if 
DW_OP_call_ref point back to proper die, but I intend to do that on high 
level.  For now I think it's enough to know that the expression itself 
is sound as far as opcode stream goes.

> If pointed-to sections overlap or something,
> it's probably useful to try to decode whatever the largest covered area is
> to cite the details.  But for holes in between properly-terminated
> pointed-to chunks, I think you can just apply the "padding logic".  i.e.,
> just report suspiciously large holes and/or nonzero garbage in holes.

In .debug_ranges, holes that I've seen are all aligned to 16 byte 
boundary.  Both beginning and the end of the hole is 16-byte aligned, 
the hole is 32 bytes wide, and usually filled with zeroes.  That 
regularity is interesting.  Dwarflint flags this as excessive; otherwise 
it tolerates zero-padding to address size.

> This garbage needs to be investigated (don't suppress the case under --gnu
> or anything).  But we don't want to spend time on that right now this week.

I've added --tolerant that suppresses that.  That's supposed for my own 
purposes, so that I don't see the avalanche of errors each time I run 
dwarflint.

PM

Attachment: signature.asc
Description: PGP signature