Re: [PATCH] elf: Add elf checks for main executable

[Florian Weimer <fweimer@redhat.com>]

* Fangrui Song:

> Should we consider different target triples as different ABI?
>
> * Debian/Ubuntu use Debian-style multiarch target triples like x86_64-linux-gnu.
> * RedHat uses target triples like x86_64-redhat-linux (considered questionable by some folks: https://reviews.llvm.org/D110900)
> * Suse uses target triples like x86_64-suse-linux (considered questionable by some folks).

Debian path layout isn't quite compatible with glibc upstream
(/etc/ld.so.cache papers over that to some extent), but that's not the
issue here.

The LLVM review refers to an internal GCC path that can be queried from
the gcc command line, so this is mostly a performance issue or
distribution integration issue (e.g., llvm/clang package postinst could
run gcc to determine the right path).  Even if you know the subdirectory
under /usr/lib/gcc to use, you still need to guess the appropriate
compiler version.  So this is really deeply internal stuff.

config.guess reports x86_64-pc-linux-gnu on these systems, so there is
no material difference.  These internal GCC paths are not required at
all to match the triplet.

> Currently there is no rigid enforcement that one target triple doesn't
> run on another, but a mechanism could be developed if you want to
> prevent "running one distro's exe on another leads to crash".
> This practice can make some software unhappy as they currently release
> binary releases which may run a different distro, which even if brittle,
> sometimes/oftentimes work.

Debian, Red Hat, and SUSE pay fairly close attention to each other and
make sure that binaries are more or less portable, as far as the core
library version constraints permit (e.g. you can move a Debian 11 binary
that uses just glibc and libstdc++ to Red Hat Enterprise Linux 8 and it
is expected to work, unless of course it relies on some Debian specifics
in its application logic).

LSB may be dead, but its spirit lives on in the form of
distribution-independent ABIs for the core run-time libraries.  A
current example is the work on the libgfortran float128 ABI for POWER.
This is a bunch of tricky ABI work which could have been avoided by a
flag day and essentially a private per-distribution ABI (the ABI would
per quasi-distribution-specific for some time because different
distributions would switch to float128 at different times).

A much smaller example is the recent glibc rseq integration, which has a
large part that can be backported without ABI changes, for distributions
that are interested in the sched_getcpu acceleration.

> As my blog post says, ELFOSABI_NONE will unlikely change EI_ABIVERSION for RELR.
> Is the proposal "if ld.bfd --pack-dyn-relocs=relr-glibc is specified,
> and the output is otherwise ELFOSABI_NONE or ELFOSABI_GNU, use
> ELFOSABI_GNU and bump EI_ABIVERSION to 4"?  This ELFOSABI_GNU is not
> elegant as RELR is not a GNU extension. OK, I have objection but not so
> strongly.
>
> Since ld.lld --pack-dyn-relocs=relr is there and won't change the
> behavior, ld.lld's relr-glibc will likely just be an alias without doing
> the EI_ABIVERSION dance.

If ld.lld will ignore what the ABI says regarding feature lockout, we
have two options:

* Ditch the idea of the lockout because it won't work reliably anyway.

* In upstream glibc, accept DT_RELR only if the lockout is also present.
  That is, ld.lld DT_RELR will not work with upstream glibc until it
  produces the proper markup.

The second approach would qualify as the nuclear option, I guess.

Thanks,
Florian