ld: -z rel and -z relr

ld: -z rel and -z relr

[Fangrui Song]

Many dynamic relocations have zero addend. IFAIK GLOB_DAT,
J[U]MP_SLOT and COPY always have 0 addend. An absolute relocation type
(R_X86_64_64 R_PPC64_ADDR64) can have non-0 addend but that is rare.

(Some other relocation types: DTPOFF/DTPMOD, but they are few)

I can understand that for object files, RELA is generally favorable
(though I'd like to know your thoughts). However, I wonder, if the
dyanmic loader supports REL, should we have a mode, -z rel, to generate
REL outstanding relocation types? The downside may be random access
reads (while with pure RELA, ld.so can blast out a bunch of writes).

The benefit will be the code size savings. I understand that many ld.so
implementations don't support REL and RELA at the same time (FreeBSD
rtld and glibc; happy to be proved wrong ;-) ), but musl ld.so supports
REL+RELA out of the box. There may be PLT complexty for these ld.so
implementations which can't support both at the same time:)

-----

R_*_RELATIVE have non-zero relocation types but they can be compressed
in a better format: RELR https://groups.google.com/forum/#!topic/generic-abi/9OO5vhxb00Y
I suspect it is strictly superior to Firefox
https://wiki.mozilla.org/Elfhack but I haven't actually looked into Firefox (probably because I don't use it...)

If GNU ld intends to support RELR, -z relr may be a good option name. I
think -z is nice because -z is reserved for ELF specific options.)

(Yes, I know LLD has --pack-dyn-relocs (since July 2018, before my
serious involvement into LLD), but if we can achieve some agreement
here, maybe LLD can add an alias.)

Re: ld: -z rel and -z relr

[Fangrui Song]

CC libc-alpha for feedback on the possibility

* supporting both REL and RELA in ld.so ..... (musl supports both REL and RELA out of the box..)
   (FreeBSD rtld supports one format, like glibc)
* supporting RELR for a compact R_*_RELATIVE representation

--

CC Cary in case the wording from
https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg
"Proposal for a new section type SHT_RELR" can be placed in a more "official" place.

On 2020-05-15, Fangrui Song wrote:
>Many dynamic relocations have zero addend. IFAIK GLOB_DAT,
>J[U]MP_SLOT and COPY always have 0 addend. An absolute relocation type
>(R_X86_64_64 R_PPC64_ADDR64) can have non-0 addend but that is rare.
>
>(Some other relocation types: DTPOFF/DTPMOD, but they are few)
>
>I can understand that for object files, RELA is generally favorable
>(though I'd like to know your thoughts). However, I wonder, if the
>dyanmic loader supports REL, should we have a mode, -z rel, to generate
>REL outstanding relocation types? The downside may be random access
>reads (while with pure RELA, ld.so can blast out a bunch of writes).
>
>The benefit will be the code size savings. I understand that many ld.so
>implementations don't support REL and RELA at the same time (FreeBSD
>rtld and glibc; happy to be proved wrong ;-) ), but musl ld.so supports
>REL+RELA out of the box. There may be PLT complexty for these ld.so
>implementations which can't support both at the same time:)
>
>-----
>
>R_*_RELATIVE have non-zero relocation types but they can be compressed
>in a better format: RELR https://groups.google.com/forum/#!topic/generic-abi/9OO5vhxb00Y
>I suspect it is strictly superior to Firefox
>https://wiki.mozilla.org/Elfhack but I haven't actually looked into Firefox (probably because I don't use it...)
>
>If GNU ld intends to support RELR, -z relr may be a good option name. I
>think -z is nice because -z is reserved for ELF specific options.)
>
>(Yes, I know LLD has --pack-dyn-relocs (since July 2018, before my
>serious involvement into LLD), but if we can achieve some agreement
>here, maybe LLD can add an alias.)

FWIW I created https://reviews.llvm.org/D80496 to add -z rel and -z rela to LLD.
Copying useful description here for easy commenting.

* COPY, GLOB_DAT and J[U]MP_SLOT always have 0 addend. A ld.so implementation
   does not need to read the implicit addend. REL is strictly better.
* A RELATIVE has a non-zero addend. Such relocations can be packed compactly
   with the RELR relocation entry format, which is out of scope of this patch.
* For other dynamic relocation types (e.g. symbolic relocation R_X86_64_64), a ld.so
   implementation needs to read the implicit addend.  REL may have minor
   performance impact, because implicit addends force random access reads
   instead of being able to blast out a bunch of writes while chasing the
   relocation array.