Re: Status 2009-02-02

[Roland McGrath <roland at redhat dot com>]

>       * Check that each rangelistptr is aligned to CU's address_size

This is canonical but not actually mandatory.

>         - DW_OP_bra and DW_OP_skip: that they don't overrun or underrun 
> opcode buffer, and that their destination address is aligned with the 
> beginning of some DIE.

Of some op in that expression block, you mean?

>       * Split into C and C++ part.  Eventually, I may get around to 
> C++-ify all the C-only GNUisms I've sprinkled across dwaflint, but right 
> now having two "halves" (high-level C++, low-level C) makes more sense.

Agreed.  (I did a quick attempt at compiling dwarflint.c as C++ earlier and
punted.)  When I finish the known-dwarf stuff in C++ so you won't need all
those C99 initializer tables in the program, it will be easier.

>       * Validate .debug_aranges overlaps, uncovered parts, etc. 
> Currently this is done in perhaps too generous a way: the code does 
> coverage analysis of ony AX section.  Except if .init, .fini. or .plt 
> are not covered at all, it doesn't flag it as an error.  Is it better to 
> assume that all "interesting" code will be in .text?  It would simplify 
> the analysis code a little.

I don't think you should be doing much of that kind of checking at all.
Overlaps are good to check, because they are always suspicious.  We can
save address validity checks for a later general high-level set of checks
also applied to DW_FORM_addr et al.

I've also added the location list C++ interface.  You can use that to apply
similar checks for addresses used in location lists.  For now, the only
check I'd recommend is that a location list's addresses all fall into the
ranges of a scope containing the one whose loclistptr attr is that list.
Note that in a location list, overlaps are always kosher (exact or not).
(Overlaps mean the value is stored in multiple places during some PC
ranges.)  It's only suspicious if one of the overlapping entries has an
empty location expression, which in fact is always suspicious.  An empty
location expression is superfluous in a location list because the entry
should just have been left out--a gap in the PC coverage means the same.

Parts of text not covered by any CU are not suspicious even if they are not
just alignment padding and so on--there are sometimes files linked in that
were compiled without -g, or assembly, which is commonly done with without
-g, or static libraries, crt1.o, etc.  That is not in the purview of
dwarflint.  At some point in the future, we can add an optional check for
"some text apparently missing debuginfo" or whatnot.  But that is not
anything to contemplate now.

The address validity checks that make sense to do by default are just that
they match some section.  In relocatable cases, it makes sense to check
that both the start and end of one pair point to the same section.  In
final-linked cases, that might still make sense but maybe not.  It probably
also makes sense to check that addresses are inside the st_value+st_size of
some symbol in the section.  Worrying about it being the right symbol is
much hair for much later.


Thanks,
Roland