[llvm] [RISCV] Add Vendor Reloc and Fallback Names (PR #116974)

[Sam Elliott via llvm-commits]

lenary wrote:

> Is the expectation that downstream tools support `R_RISCV_CUSTOM<n>` as non-canonical aliases when they are given a defined meaning? There doesn't seem to be an ELF_RELOC_ALIAS equivalent to allow for that, so such downstream (ourselves included) would have to add extra cases to RISCVAsmBackend::getFixupKind manually. We can do that if needed, but it'd be nicer if upstream supported this more directly.

I have a solution for `getFixupKind` to support using vendor relocation names "correctly", but I'm waiting for review on the ABI extension I've written before I can release the spec and open a PR for the corresponding implementation.

Broadly, my intention is to add another header, `ELFRelocs/RISCV_nonstandard.def`, with a `ELF_RISCV_NONSTANDARD_RELOC(vendor_symbol, name, id)` macro, and to hook that macro into `getFixupKind` so you can use the `name` directly. The reason for including the `vendor_symbol` is so that we can start to have other places use the mapping correctly. I'm not familiar with the cheri relocations, and whether they use the R_RISCV_VENDOR with a named symbol, but I took a quick look at the [corev relocs](https://github.com/openhwgroup/corev-llvm-project/blob/development/llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def) and an example from that in my scheme would be `ELF_RISCV_NONSTANDARD_RELOC(COREV, R_RISCV_CVPCREL_UI12, 224)`. The nice thing about this is it means different places in LLVM can opt into the pretty-printing (rather than the fallback) behaviour, depending on whether they want a 1:1 mapping or have more information available.

A lot more reworking of llvm-objdump will be required to support printing out the right name depending on the vendor relocation - in the meantime, it will print out `R_RISCV_CUSTOM<n>` - which I don't think is wrong, even though it could do better.

I'm trying to juggle my priorities fairly carefully, and have had to make the hard decision to prioritise the linker implementation of my specification, rather than reworking llvm-objdump, so until I can get to it (likely after 20.0) I think downstream implementations will just have to keep some modifications to `ELFRelocs/RISCV.def` if they want their name to be printed out rather than the `R_RISCV_CUSTOM<n>` name (and presumably those downstream implementations are, right now, ignoring the `R_RISCV_VENDOR` implementation when they are printing anyway).

I hope this is a reasonable/acceptable way forwards?

https://github.com/llvm/llvm-project/pull/116974