>> We saw cases in the wild where an arange entry was
terminated early.
>> That is, the 0,0 entry occurred before the end of the particular
>> arange buffer. There is a bug, maybe closed, in Red Hat bugzilla for
>> this.
That would get a citation for unnecessary padding (with zero or non-zero
bytes, depending on where it is) and probably also for addresses covered
with CUs, but not with aranges. I've added a test case for that now,
just to be sure.
Yes, I thought those would be caught already. Good that they are. For
paranoia, it would be good to dig up a real-world case like Tom saw and
verify that it's caught and diagnosed correctly. But if Tom can't find
the case easily and you already have a synthetic test case, that's fine.
>> Consider checking that every CU has an arange entry.
>> This is not strictly required, but it is nicer for consumers.
>> ISTR filing a bug about this in GCC bugzilla.
>
> I think this comes under what we call "connectivity" checks, and might be
> done already. .debug_aranges should be deriveable from scratch from the
It wasn't but is now. It emits a warning in --strict.
Every CU that has any PCs (i.e. compile_unit has low_pc, high_pc, or ranges
attributes at all), that is. In today's GCC, I'm not sure there is ever a
CU with no PCs at all, except for a type_unit (-gdwarf-4). With compression,
we will certainly generate partial_unit entries with no PCs eventually.
This should be a default warning, because libdw and things using it will
fail completely to notice the CU for by-address lookups if it has no
.debug_aranges entry.
> DIE trees (and our writer/compressor will always do that and
ignore the
> original contents). So I think we already intend to compare the data
> completely to what we would build from scratch. Petr should know if any
> parts of that checking are still missing.
Up until now we checked that aranges cover everything that's claimed by
CUs. Now I've added the reciprocal check, that looks whether CU claims
match what aranges cover.
Right, any mismatch there is highly suspect.
Good stuff!
Thanks,
Roland