Re: sequential reading of .debug_loc

[Roland McGrath <roland at redhat dot com>]

> One thing that the connectivity will be useful for is checking if 
> DW_OP_call_ref point back to proper die, but I intend to do that on high 
> level.  For now I think it's enough to know that the expression itself 
> is sound as far as opcode stream goes.

To a first approximation all consideration of the actual location
expression contents is higher-level stuff.  It's also stuff we can put off
for later, since we aren't very close to generating those exprs ourselves
yet (just copying blind).  The only things that would totally confuse libdw
at a deep level is if the block form is bogus (i.e. bad length).  So loc
stuff not top priority really.

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

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.

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.

> 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.)

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.

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


Thanks,
Roland