Refactoring `RzBinReloc`

[Rot127]

RzBinReloc is supposed to be a general abstraction for all kind of relocations.

It has some shortcomings we should address. Here an overview of what came up so far:

Existing issues:

• ELF - Handle MIPS PLT properly #5200 (issues with MIPS and contains valuable resources to learn about PLT/GOT/indirect functions etc.)
• PLT stub names not being resolved properly #153

rizin/librz/include/rz_bin.h

Lines 707 to 729 in a47402a

	typedef struct rz_bin_reloc_t {
	RzBinRelocType type;
	RzBinSymbol *symbol;
	RzBinImport *import;
	st64 addend;
	ut64 vaddr; ///< the vaddr where the value should be patched into
	/**
	* \brief The offset into the binary file.
	* Note: This is not related to the physical addresses an MMU would manage!
	*/
	ut64 paddr;
	ut64 target_vaddr; ///< the target address that the patched reloc points to
	ut64 section_vaddr; ///< the subsection address
	ut32 visibility;
	bool additive;
	const char *print_name; ///< Name of the relocation type. NULL if none is specified. Not setting this field is deprecated.
	/* is_ifunc: indirect function, `addend` points to a resolver function
	* that returns the actual relocation value, e.g. chooses
	* an optimized version depending on the CPU.
	* cf. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
	*/
	bool is_ifunc;
	} RzBinReloc;

Issues

• RzBinRelocType is not really the type of the relocation but the number of bits patched (the size). But as enum it has too few values (8, 16, 24, 32, 64). But relocations also patch 22, 13 or any number of bits. It should be a number. Also it doesn't know if the patch location has to be aligned or not. It maybe refers to the width of the value being patched.
• The type of a relocation should be grouped differently. Currently there seems to be a categorization of relocs into adds a value to a symbol address, sets a constant value, something with vaddr, something with indirect function (see: elf_relocs_conversation.c - reloc_convert_add, reloc_convert_set, reloc_convert_vaddr, reloc_convert_ifunc).
  I think it would be groupings like patches PLT, patches GOT, patches a constant, patches a symbol address, copies data from a to b. These groupings should be extensible, because arch devs come up with the funniest patching mechanisms for their binaries.
• The calculation of the patch value is currently limited to Symbol address + ADDEND. But these calculations can be vastly more complex. E.g. updating of indirections in the GOT or PLT. Or the value depends on runtime values. Especially, when for PLT patching. Some "relocs" just copy data, like R_SPARC_COPY.