This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dwarflint


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]