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