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: sequential reading of .debug_loc


Roland McGrath wrote:
> The ref connectivity is something that is more handy to do at the low-level
> scan since you have ref validation at hand there already.  (But note that
> I'm pretty sure GCC never generates DW_OP_call* at all, so not a practical
> priority.)  Also, the reloc checking really needs to grok the opcodes to

DW_OP_call_ref in particular contains an address that is in other DSO 
(must be relocated).  That's what I wanted to leave on high level.  The 
rest can be done on low level, right.  But I'll leave it alone for now, 
it's a bit more work.

> know where relocs are sane within an expr (DW_OP_addr and const[48] only I
> think, plus call_ref), and that fits into the low level as we've planned it.

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.

> Since you're there anyway and it's trivial, it doesn't hurt to do the
> const8-vs-32 check and the bad-offsets checks for the branching opcodes.
> Anything beyond that can be in high-level and wait for when we have
> expr-grokking smarts that do something.

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.

> Note that you want to apply all the same expr checks for block form attrs
> that are VS_location.  So unify the code and treat each loclist entry as if
> it were a block2 form, but you'll need some appropriate variation in the
> offset reporting in messages.

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.

>> 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.
> 
> Please start a wiki page with these notes and post the link.  (It would be
> great if you also note anything else we've talked about that I've already
> forgotten.)

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.

> Usually zeros or always all zeros?  Any nonzero garbage ever is thoroughly
> suspicious.  Just spurious zeros are likely to be some simple fence-post
> bug in GCC's generator or suchlike as we noticed with empty .debug_aranges.

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.

>>> This garbage needs to be investigated (don't suppress the case under --gnu
>>> 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 
>> dwarflint.
> 
> This isn't coming up in the self-test is it?  Just in the old data produced
> by the fc9 compiler?

No, self test passes fine (but that's F9, too).

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.

PM

Attachment: signature.asc
Description: PGP signature


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