Re: sequential reading of .debug_loc

[Roland McGrath <roland at redhat dot com>]

> DW_OP_call_ref in particular contains an address that is in other DSO 
> (must be relocated).  

Well, not really (relocation).  But in theory it might, like any ref_addr.
So, yeah, it's high-level stuff (and for much later, the real loc stuff)
apart from the raw reloc-in-expected-places check.

> I want to do ranges coverage .debug_ranges, _aranges and _loc (i.e. all 
> covered and no overlap except for _loc).  Then I'll do reloc stuff I think.

Ok.  Note that overlap is potentially kosher in cases where both offsets
point to the start of a proper entry.  You'll never see this today, I'm
pretty sure.  But our producer will probably generate it.  e.g. consider a
CU containing one function, whose ranges will match the CU's exactly.
(In all likelihood noone will ever generate any overlaps except reuse of
the exact same offset, not any one offset that's a trailing portion of a
set starting at another offset.  But it's not theoretically unkosher in
case there is duplication that would be correctly consolidated that way.)

> Done & pushed.  Since I already check if the skip offset falls within 
> the expression, I also put it a check that the offset ends up at the 
> beginning of another opcode.

Good.  That check on all the branching opcodes can make it safe for the
high-level stuff to be purely "semantic" and not worry about bogons that
can't be represented as a proper stream of abstract stack operations.

> That's how it's done.  Location expression validator is called both from 
> .debug_loc validator and .debug_info validator as necessary. 
> where-structs take care of pinpointing the message appropriately.

Great!

> https://fedorahosted.org/elfutils/wiki/SuspiciousDebuginfoCases
>
> I'll go through our mailing and fill the page over the weekend, or when 
> I run off my mind's coding quota.

Thanks!  We should put it on a to-do list to investigate these fully.
We might get some help on that part from the Archer project folks.  I
don't think we need to actively pursue that now.  It's my hope that we
can produce a few more tools helpful in diagnosing and explaining this
stuff before we ask anyone to do any big push of resolving where the
bogons came from.

> Usually zeroes.  I.e. almost always zero padding, but a couple holes 
> contain unreferenced non-zero bytes.  Chances are that's just a 
> composite of two holes, one with garbage and the other with padding 
> zeroes.  But the garbage (or unreferenced data) is there, in any case. 
> Maybe I just don't dereference some attribute with rangelistptr-class 
> form, but per the spec, that should only be DW_AT_ranges.

With the high-level checks we'll uncover any unexpected attributes that
might be the culprit.  (With a tree-walk iterator, which we haven't
really needed yet, it also becomes quite simple to check all formdata
attrs for an offset value, in case we have a known attribute
misclassified or something.)  But I concur, DW_AT_ranges ought to be it.
So this garbage (any nonzero garbage, that is) is suspicious.

> The avalanche of errors is coming up when I run dwarflint on my bulky 
> test-case, which is libsc680lx.so.debug from openoffice.org.  It is F9 
> binary, but re-running dwarflint on openoffice.org's libsclx.so.debug 
> from x86_64 Rawhide gives similar results.

Yeah, sure looks like garbage to me.


Thanks,
Roland