* 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