Generalize relocTargetBits to work with non-word-aligned relocation addends (as in PowerPC and RISC-V)

[RyanGlScott]

While working on #35, I realized that the relocTargetBits method of IsRelocationType is not capable of handling certain relocation types in PowerPC code. To recap:

elf-edit/src/Data/ElfEdit/Relocations/Common.hs

Lines 91 to 98 in 3ba7d71

	-- | Return the number of bits that the rel entry should use for the addend.
	--
	-- This is commonly the size of a pointer, but may be smaller for some
	-- relocation types. This is used for rel entries, where to compute
	-- the addend the next @ceiling (bits/8)@ bytes is read out of memory
	-- as a list of bytes and the low @bits@ are interpreted as a signed
	-- integer (where low uses the elf's endianness) and sign extended.
	relocTargetBits :: tp -> Int

Currently, relocTargetBits assumes that the bits needed for the relocation addend will always start at a word alignment. For instance, here are the different addend sizes in the x86-64 System V ABI:

Each relocation entry is 64 bits, but certain relocation types may only use 8, 16, or 32 bits of the entry (starting from the LSBs). Regardless, the addend calculations will always happen at 64-bit-sized word boundaries, which greatly simplifies the bitwise arithmetic needed to compute the addends (see this code in macaw).

Things aren't quite so simple in PowerPC, however. For instance, here are the different addend sizes in the PPC32 ABI:

This time, each relocation entry is 32 bits. What is unusual is that the low24 and low14 relocation fields do not start from the LSBs of a 32-bit word, but rather from somewhere in the middle of the word. A low24 relocation addend starts from the 7th LSB of the word, and a low14 relocation addend starts from the 17th LSB of the word. This means that we cannot use the addend-computing code in macaw as-is with low24 or low14 relocation fields, as this code does not account for the bit offsets required.

In order to fix this, we will likely need to augment relocTargetBits with additional information about bit offsets (the PPC32 refers to this as "displacement"). Luckily, low24/low14 relocation fields aren't super common, so I am opting not to fix this issue for now, instead leaving this here as a reminder to revisit the issue should we need to support such relocations properly.

[RyanGlScott]

RISC-V also has some wonky relocation fields, where the imm bits do not necessarily occupy contiguous regions of the field:

(Screenshot taken from here)

[sauclovian-g]

riscv has some even more exciting immediate fields in the C (compressed instructions) extension, though I'm not sure offhand if any of them are expected to be relocation targets.

sparc also has discontiguous fields, not that there's ever likely to be sparc support...