Add CREL support

[kito-cheng]

CREL is a LEB128-based relocation format, which can be significantly reduce the object size and also remove the limitation of the number of the relocation types.

• RISC-V has larger object files size than other target because linker relaxation need all local symbol information, and most of relocation is come with zero addend, so this part can be save ~7 byte for each relocation in general.
• RV32 and RV64 share same ABI spec, so the type of relocation will limited to 256 due to elf32 limitation.

Related discussions:

• https://groups.google.com/g/generic-abi/c/yb0rjw56ORw
• LLVM implementation: [MC,llvm-readobj,yaml2obj] Support CREL relocation format llvm/llvm-project#91280
• Add RELOCID for vendor-specific relocations #423 (comment)

[jrtc27]

I don't think we should be adopting draft gABI proposals, and if and when it becomes an official part of the gABI there's nothing for us to say because our psABI only mentions (AFAIK) the relocations, leaving the representation to the gABI.

[MaskRay]

Thanks for the interest and support for CREL. RELLEB was an earlier, abandonded name.

As I mentioned in the RELR issue: In practice, as long as there's significant benefit and broad support from GNU, LLVM, and a sizeable user base, the generic ABI inclusion becomes less relevant.

Based on my discussions, Arm, RISC-V, and s390x architectures seem open to including SHT_CREL in their generic ABI ranges.
Though, they wouldn't lead toolchain development as they don't receive user requests.

I agree replicating the existing specification of CREL is unnecessary.
Once LLVM support is ready and the generic ABI is comfortable with CREL using section code 20, referencing the existing spec could be helpful.

In practice, as long as we choose a section code, achieve agreement from GNU and LLVM, and commit to its stability, formal approval from the generic ABI might not be essential. (Let's be honest, updates beyond constants (new machine code, ELFCOMPRESS_ZSTD) haven't happened for the generic ABI for many years.)

RISC-V's buy-in is crucial for aligning GNU and LLVM. Thanks again.

[kito-cheng]

I don't think we should be adopting draft gABI proposals, and if and when it becomes an official part of the gABI there's nothing for us to say because our psABI only mentions (AFAIK) the relocations, leaving the representation to the gABI.

Yeah, I generally agree, but it's kinda chicken egg issue, CREL need implementation and support from targets, so that can become official gABI, the goal of creating this issue is kinda explicitly to say we are interesting on this, then @MaskRay can take this as a more concrete reference/evidence to push that forward :)