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