> >> 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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
