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

[Fangrui Song <maskray@google.com>]

On 2021-12-14, Florian Weimer wrote:
>* Fāng-ruì Sòng:
>
>> On Tue, Dec 14, 2021 at 1:03 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> * Fāng-ruì Sòng:
>>>
>>> > If the question is: "if upstream glibc implements the diagnostic, will
>>> > ChromeOS port the patch to their glibc".  My reply is non-authoritative,
>>> > but if this has not been a problem for more than 3 years now, I do know
>>> > see large value backporting the feature to their older glibc release.
>>>
>>> But if you don't backport, you can teach your toolchain to start
>>> producing binaries that fail to load on older glibc.  You will have to
>>> keep creating binaries that lack proper markup.
>>>
>>> My concern is that we go through all this trouble to implement a version
>>> proper handshake, and yet Google binaries will still crash on older
>>> glibc.
>>
>> 3+ years ago, "still crash on older glibc" was considered an
>> acceptable compromise as the scenario (cared by some upstream glibc
>> folks) is simply unsupported (and by many other groups).
>>
>> Now after 3 years, (while this is unsupported) back porting RELR
>> executables to less-than-3 year old ChromeOS would still work because
>> all glibc releases in the past 3 years support RELR. If you consider
>> symbol versioning, many symbols get new symbols which won't run on
>> 3-year-old glibc anyway.
>
>I have a feeling we are talking past each other.

I think it is just a fundamental difference in our viewpoints:

* I share the feeling with Android, ChromeOS, FreeBSD, Fuchsia, NetBSD, and
   Solaris): the "time travel compatibility" development model is simply
   unsupported and as a compromise poor diagnostics are acceptable.
   (For some groups "unsupported" means "cannot run" with other lockout
   mechanism.)
   The Gentoo Linux developer leans on this side.
   An Void Linux developer and an Arch Linux developer seem to lean on this side, too.
   (They just did not participate the discussion.)

* You and HJ really want a diagnostic for "time travel compatibility",
   even if RELR will remain non-default knob in majority Linux world for
   a long time.

The two camps generally don't interact, but here for the glibc RELR
patch ("Can DT_RELR catch up glibc 2.35?") we interact.

>Based on previous mail exchanges, I think you would use an lld option to
>build binaries which use DT_RELR but do not have any version lockout for
>older glibc (so that these binaries still work on your older glibc with
>DT_RELR).

Perhaps I am not clear about the question. Let me rephrase:
ld.lld --pack-dyn-relocs=relr will remain the current semantics.
It won't add version symbol/bump ABIVERSION to NOT run on older glibc.

Even if a glibc mechanism is developed, it likely has low/no adoption in the first
camp since (1) back porting requires some efforts (2) the mechanism solves a subset
of problems. And mostly importantly, the first camp people don't
consider this a problem.