Bug 818376 – [toolchain] Adopt SHT_RELR/DT_RELR relative relocation format

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description emacsray 2021-10-15 21:56:52 UTC]

The SHT_RELR/DT_RELR format encodes relative relocations in a very efficient way (quite usually takes just 3% or smaller space).
The size optimization can greatly decrease the virtual memory size of PIE and shared objects with many R_*_RELATIVE relocations.

The SHT_RELR/DT_RELR relocation format requires linker and loader support.

* On the linkder side, ld.lld has supported .relr.dyn/SHT_RELR/DT_RELR (`--pack-dyn-relocs=relr`) for a long time and the support has been stable since 2019-09 (after I fixed an address oscillating bug).
* On the loader (glibc ld.so) side, a patch exists https://sourceware.org/pipermail/libc-alpha/2021-October/131768.html
  but lack of GNU ld support may impede its adoption among Linux distributions.
  User support is also important to push the patch forward. (ia64 according to folks isn't an issue. glibc doesn't implement ELFCLASS32 for ia64 AFAICT.)

(Worth noting that the Linux kernel's arm64 port supports this format since 2019.)

So I file this ticket seeking for support (comment on https://sourceware.org/bugzilla/show_bug.cgi?id=27924). I hope that with sufficient attention from users,
someone (e.g. a GNU ld maintainer) will eventually stand up and implement `--pack-dyn-relocs=relr` for GNU ld (https://sourceware.org/bugzilla/show_bug.cgi?id=27923).

Reproducible: Always

[Comment 1 Tee KOBAYASHI 2021-10-15 22:56:59 UTC]

What can be done on Gentoo side?

Personally it would be nice to have it supported by ld.bfd in the future to be usable on Android 12 (https://github.com/termux/termux-packages/issues/7382).

[Comment 2 emacsray 2021-10-16 01:16:59 UTC]

(In reply to Tee KOBAYASHI from comment #1)
> What can be done on Gentoo side?
> 
> Personally it would be nice to have it supported by ld.bfd in the future to
> be usable on Android 12
> (https://github.com/termux/termux-packages/issues/7382).

Android and Chrome OS have been using ld.lld --pack-dyn-relocs=relr for quite some time. The feature I want to push forward is glibc's DT_RELR support. Distributions' support will be great...

I'll also add a note that RELR is more efficient than Firefox's ELF hack and may render it unneeded (https://glandium.org/blog/?p=1177)

[Comment 3 Sam James 2022-06-10 04:51:57 UTC]

Status update:
- Binutils 2.38 supports it
- glibc 2.36 (not yet released) will support it.

It's _possibly_ a candidate for 22.0 profiles as default.

[Comment 4 Andreas K. Hüttel 2022-10-12 21:41:50 UTC]

(In reply to Sam James from comment #3)
> Status update:
> - Binutils 2.38 supports it
> - glibc 2.36 (not yet released) will support it.
> 
> It's _possibly_ a candidate for 22.0 profiles as default.

This needs discussion since the feature is quite new.
Then again, people will have some time to switch to the new profiles.

[Comment 5 Andreas K. Hüttel 2022-10-22 16:30:14 UTC]

I guess for ld.bfd this would be -z pack-relative-relocs

However, from the manpage:

           pack-relative-relocs
           nopack-relative-relocs
               Generate compact relative relocation in position-independent executable and shared library.  It adds "DT_RELR", "DT_RELRSZ" and "DT_RELRENT" entries to the dynamic
               section.  It is ignored when building position-dependent executable and relocatable output.  nopack-relative-relocs is the default, which disables compact relative
               relocation.  When linked against the GNU C Library, a GLIBC_ABI_DT_RELR symbol version dependency on the shared C Library is added to the output.  Supported for
               i386 and x86-64.

[Comment 6 Sam James 2023-02-21 09:15:48 UTC]

This is in the 23.0 profiles in preparation but we need to drop it for non  amd64 as it doesn't exist there yet.

(IIRC one other arch supports it but I haven't tested it much on non-amd64)

[Comment 7 Andreas K. Hüttel 2023-08-20 21:15:25 UTC]

(In reply to Sam James from comment #6)
> This is in the 23.0 profiles in preparation but we need to drop it for non 
> amd64 as it doesn't exist there yet.
> 
> (IIRC one other arch supports it but I haven't tested it much on non-amd64)

Depending on how long the 23.0 stuff takes us some other arches might catch up. :o)

[Comment 8 Larry the Git Cow 2023-11-25 23:13:37 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=57250bdaec26224add7447e8d439d75960645737

commit 57250bdaec26224add7447e8d439d75960645737
Author:     Andreas K. Hüttel <[e-mail]>
AuthorDate: 2023-11-25 23:12:22 +0000
Commit:     Andreas K. Hüttel <[e-mail]>
CommitDate: 2023-11-25 23:13:25 +0000

    profiles, 23.0: drop global DT_RELR and enable it only on x86 and Power
    
    Bug: https://bugs.gentoo.org/show_bug.cgi?id=818376
    Signed-off-by: Andreas K. Hüttel <[e-mail]>

 profiles/default/linux/amd64/23.0/make.defaults | 4 ++++
 profiles/default/linux/ppc/23.0/make.defaults   | 4 ++++
 profiles/default/linux/ppc64/23.0/make.defaults | 4 ++++
 profiles/default/linux/x86/23.0/make.defaults   | 4 ++++
 profiles/releases/23.0/make.defaults            | 4 ++--
 5 files changed, 18 insertions(+), 2 deletions(-)

[Comment 9 Larry the Git Cow 2024-03-25 18:49:11 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fac51cc9370713f6b2764e8e03ee2ff8d652c3af

commit fac51cc9370713f6b2764e8e03ee2ff8d652c3af
Author:     Sam James <[e-mail]>
AuthorDate: 2024-03-25 18:46:04 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-03-25 18:48:58 +0000

    profiles/default/linux/ppc/23.0: drop DT_RELR
    
    bfd doesn't support DT_RELR on ppc32.
    
    Bug: https://bugs.gentoo.org/818376
    Signed-off-by: Sam James <[e-mail]>

 profiles/default/linux/ppc/23.0/make.defaults | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

[Comment 10 Andreas K. Hüttel 2024-04-10 03:47:54 UTC]

This is fixed in the 23.0 profiles (available and stable now). Closing.

(Well, at least for amd64 where the relocation exists. More arches will follow.)