dwarflint relocs

[Roland McGrath <roland at redhat dot com>]

I'm thinking about the attr value interfaces and not making much progress yet.
So I thought I'd give a brain dump about dwarflint doing reloc checks.
Petr might run out of low-level section checks to implement before I get
the attr value stuff in shape to use it as the basis for high-level checks.

For some test data, try:
	mkdir k; eu-unstrip -k -a -m -d k
(with kernel-debuginfo installed, or s/-k/-K/ for many more files).

In an ET_REL file, you need to check for reloc sections applying to each of
the sections you check.  That's any section with sh_type SHT_REL or SHT_RELA
and nonzero sh_size, and sh_info matching the section index of a section
you check.  Complain if there are multiple reloc sections pointing to the
same debug section.  Each reloc section's sh_link is the section index of
the symtab it uses; complain if they don't all point to the same section.

You must examine the reloc section before you can check the corresponding
section.  Check all its relocs' type with ebl_reloc_simple_type (see
libdwfl/relocate.c example).  Only WORD, SWORD, XWORD, SXWORD make sense.
If any relocs have types we don't grok, you could either blacklist the
section (as if you'd found a bad format error parsing the relocated section
itself), or just report the individual bad relocs in-line in the checks.
Make a table of the relocs sorted by r_offset.  (Given plain READ or
READ_MMAP_PRIVATE, you could just sort the reloc section data in place.)

As you check each section linearly, you can keep a pointer/index that
follows along in the reloc table, which is now sorted by offset into the
section.  If you cross the offset touched by the next reloc when you aren't
expecting it, complain.  You expect a reloc (but don't require one) when
looking at a fixed-size 4-byte or 8-byte quantity (i.e. usually offset_size
or address_size).  The reloc type has to match the size you are decoding.

For an SHT_REL table, the value decoded from the section is the "addend" to
yield the pair (symndx, addend) from the reloc.  For an SHT_RELA table, the
pair is (symndx, r_addend); the value in the section is ignored, and you
should complain if it's not zero.

When you hit the relocatable value, you were either looking for an offset
in some section or for a target value.  i.e., the CU header's offset into
.debug_abbrev, a strp, ref_addr forms, etc.  For the *ptr attribute classes
(offsets into .debug_{line,loc,ranges,macinfo}) you need to match the known
tag and attribute; in the long run we'll do that with a centralized map of
known stuff, but for the moment you can just hard-code DW_AT_ranges et al.
This yields what section makes sense for the value: a particular one of the
debug sections, or any allocated section.

If symtab[symndx].st_shndx does not match the expected debug section's
index, complain.  If a target value is what's expected, then complain if
it's not either SHN_ABS, an SHF_ALLOC section, or SHN_UNDEF.

For the offsets into debug sections, you then use st_value+addend in place
of the value decoded from the section, in your connectivity maps et al.

If relocs occur inside a block form, that has more cases.  
We'll get to that later.  Just note it for now.

For DW_FORM_addr and for data forms of address_size (when they are class
constant, worry about that later), an SHN_UNDEF reloc is acceptable.
In all other places, reject SHN_UNDEF.

In all begin/end address pairs, such as in .debug_ranges, .debug_loc, and
.debug_aranges entries, if either the begin or end is relocated, complain
unless both have relocs and both relocs' symbols have matching st_shndx and
begin's st_value+addend <= end's st_value+addend.

In DW_FORM_addr and all header/other section places where an address is
specifically required, do a "suspicious" warning if there is no reloc for
that spot and its in-place value is not zero.  (This in ET_REL files only,
of course.)


Is that plan all clear?


Thanks,
Roland