Roland McGrath wrote:
> In the mean time, I switched back to the old way of validation,
> 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
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