Add RELR support

[kito-cheng]

RELR is a new relocation format to compress the R_RISCV_RELATIVE relocation, which can save lots size for the shared libraries.

• RELR already supported within glibc since 2.36.
• https://maskray.me/blog/2021-10-31-relative-relocations-and-relr

[jrtc27]

Do we need to say anything? It's all in the gABI, I don't think there's anything unspecified for the psABI.

[MaskRay]

While I'm not as familiar with other RISC-V repositories for recommended ABI practices, I understand the intent of this PR seems to be promoting good habits.

I agree replicating the existing specification of RELR is unnecessary. We don't even need to mention it.
Technically, RELR might be considered pre-standard in the generic ABI. However, 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.

[kito-cheng]

Do we need to say anything? It's all in the gABI, I don't think there's anything unspecified for the psABI.

IMO at least we may mention something like what AArch64 ABI do: allow mixture the relocation format within single binary but disallow use more than one type for an address.

A binary file may use REL or RELA relocations or a mixture of the two (but multiple relocations of the same place must use only one type).

https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#addends-and-pc-bias

[kito-cheng]

@MaskRay

Technically, RELR might be considered pre-standard in the generic ABI. However, 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.

I don't know too much on the gABI standardized flow, what's the status about the RELR, and ... I know there is mailing list and latest (?) draft https://www.sco.com/developers/gabi/latest/contents.html, does here some git repo for latest status? and what's the formal flow for that?

My intention is having some more formal reference if possible :P

[rui314]

@kito-cheng

IMO at least we may mention something like what AArch64 ABI do: allow mixture the relocation format within single binary but disallow use more than one type for an address.

Many linkers don't support both REL and RELA for a single architecture, so I don't think we want to allow that too casually. In addition to that, it's not really needed to support RELR and kind of off-topic, I think?

[MaskRay]

Technically, RELR might be considered pre-standard in the generic ABI. However, 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.

I don't know too much on the gABI standardized flow, what's the status about the RELR, and ... I know there is mailing list and latest (?) draft sco.com/developers/gabi/latest/contents.html, does here some git repo for latest status? and what's the formal flow for that?

There is unfortunately no git repo.

While some constants (e.g. e_machine and EI_OSABI values, ELFCOMPRESS_ZSTD) have been defined, no functional update has happened.

My intention is having some more formal reference if possible :P

Thanks:)

---

The Executable and Linking Format was originally developed and published by UNIX System Laboratories (USL) as part of the Application Binary Interface (ABI).
The Tool Interface Standards committee (TIS) selected the evolving ELF standard and developed the Executable and Linking Format (ELF) Specification Version 1.2 in May 1995.

The TIS Committee grants you a non-exclusive, worldwide, royalty-free license to use the information disclosed in this Specification to make your software TIS-compliant; no other license, express or implied, is granted or intended hereby.

The committee appeared to be dismissed. On www.sco.com, they claim that its a SCO copyright.

In 2011, the SCO group's Unix software assets were sold off to UnXis, which renamed to Xinuos in 2013.
John Wolfe, the last maintainer at SCO and UnXis/Xinuous, oversaw updates until his departure from Xinuos in 2015.
The generic ABI then became unmaintained.

The last update of https://www.sco.com/developers/gabi/latest/contents.html was SHF_COMPRESS in June 2013.
(See also ELF Section Compression).

---

(I am going to add the following to my next blog post, as I think many folks want to know the role of the generic-abi group and the status.)

A neutral Google Group not affliated with Xinuous exists for discussing the generic ABI.
It served as a platform for employees from various operating system vendors to collaborate, but in recent years, participation has dwindled to primarily representatives from Oracle Solaris (just Ali Bahrami) and the GNU toolchain.

However, this low activity is not a major concern, as worthy changes to the object file format that would benefit many ELF operating systems are rare.

---

In April 2020, Cary Coutant reached a preliminary agreement with Xinuos.
However, the future remains uncertain.
While some constants (e.g. e_machine and EI_OSABI values, ELFCOMPRESS_ZSTD) have been defined, no functional update has happened.