Can DT_RELR catch up glibc 2.35?

Fangrui Song
Fri Nov 12 07:47:23 GMT 2021

I am glad that
("[PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924]") gets
some traction and many folks acknowledge the size benefit.
(On my Arch Linux, I measured 8% decrease for my /usr/bin.)

There are two potential issues.

1. Lack of "Time travel compatibility" detector
2. Some folks feel that unable to test with scripts/ is a problem.
   (ld.lld --pack-dyn-relocs=relr (since July 2018) is the only linker implementation
   and scripts/ doesn't have an lld configuration)

Let me address them for you.



"Time travel compatibility" means running a new object on an old system.
A new object using DT_RELR doesn't have the R_*_RELATIVE part in
.rel.dyn/.rela.dyn and is destined to crash.

If the GNU ld implementation (which may take a while) adopts an
undefined versioned .dynsym symbol (e.g. _dl_have_relr,
we can guarantee old will report an error.
The undefined symbol needs to be versioned because ld -shared (default
to --allow-shlib-undefined) does not error on unversioned symbols. Say
GNU ld adopts something like _dl_have_relr@GLIBC_2.40 . Now it is funny as GNU
ld needs to know the glibc version "GLIBC_2.40", not just the stem
glibc-flavored symbol name "_dl_have_relr".

There are non-Linux OSes which don't like a "_dl_have_relr" symbol name.
GNU ld would have to provide options in two flavors, one with
_dl_have_relr@GLIBC_2.40, one without. Among glibc systems, there are
plenty of distros there which don't rigidly require a friendly
diagnostic for "time traverl compatibility", e.g. I pretty sure many
Gentoo Linux folks doing aggressive optimizations know that their
executables don't run on old systems.

An alternative to _dl_have_relr is EI_ABIVERSION. That is probably even
less appealing because bumping the version locks out many ELF consumers.
In addition, I noticed that Debian 2.32 just seems to ignore EI_ABIVERSION.

% r2 -wqc 'wx 22 @ 8' a; readelf -Wh a | grep ABI; ./a
   OS/ABI:                            UNIX - GNU
   ABI Version:                       34



Fetching a prebuilt llvm-project 13.0.0 which supports many Linux distros is
difficult. The accessibility of ld.lld 13.0.0 is certainly nice but I wish that
you don't consider it a blocker as llvm-project 13.0.0 has arrived on many
distros and will arrive on others soon.

Moreover, I want to emphasize that the core logic is below 30 lines.  It is
isolated enough and uses sufficiently few interfaces so as NOT to cause
maintenance burden to other (tricky) parts of


I installed Gentoo Linux last weekend for fun and chatted with some Gentoo
Linux folks who use -fuse-ld=lld. I am sending this message because I think I
should make the feature benefit them earlier. I know some Arch/Debian Linux
users are interested in the feature as well but they may have to wait longer
for GNU ld (their system linker) support.

I sincerely hope that the patch can catch up glibc 2.35.  By making the
functionality available in an older consumer, we just avoid more "time
travelling compatibility" problems.  Landing the consumer and the producer at
about the same time is actually the bane of many compatibility problems.

More information about the Libc-alpha mailing list