Re: Can DT_RELR catch up glibc 2.35?

[Florian Weimer <fweimer@redhat.com>]

* Fangrui Song via Libc-alpha:

> A synthesized versioned undefined dynamic symbol can indeed catch "time
> travel compatibility", but the mechanism would be the first time ld adds an option variant
> for a particular libc implementation (glibc) locking out all other
> implementations: --pack-dyn-relocs=relr-glibc or -z relr-glibc.
> Sigh, it is really not pretty.

There are already other features that do not work with other libcs,
e.g. --audit, --filter, --auxiliary.  And --dynamic-linker tends to lock
out other libcs, too.  And it's a bit hard to argue against this given
that --pack-dyn-relocs=relr works the same way against upstream glibc.

However, I happen to dislike the glibc-tied approach as well, and would
like to see an ELFOSABI bump, along with a kernel fix to make it stick
for main programs as well.

> We know many other libc implementations don't want to synthesize such a
> symbol.

It's been used for other toolchain features before, that's where the
idea comes from.

> "If user is deploying a *opt-in* feature that requires proper dynamic
> loader support, I would expect they know the environment they are targeting."
>
> May I suggest that: if a glibc distro really worries that users deploy
> ld.lld --pack-dyn-relocs=relr on their new system and back port that to
> old systems, just remove DT_RELR support from your local glibc? Since
> ld.lld --pack-dyn-relocs=relr  doesn't work on your system with glibc
> 2.35, people wouldn't complain about not working on older versions.

In a sense, isn't that what's happening?  Albeit on an upstream scale.

Thanks,
Florian