Roland McGrath wrote:
The ref connectivity is something that is more handy to do at the
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
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
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
> 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
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
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
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.