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

[Fangrui Song <maskray@google.com>]

On 2021-12-14, Adhemerval Zanella wrote:
>
>
>On 14/12/2021 06:03, Florian Weimer 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.
>
>Is ChromeOS glibc really binary compatible with glibc from other general
>Linux distributions? Different from google/grte branches, ChromeOS seems
>to work by patching upstream glibc and my impression is they not really care
>nor aim to be (Fāng-ruì remarks also strength this idea).

Not binary compatible, like two very different Linux distributions (e.g.
a musl one vs a glibc one; a pure llvm-project toolchain based one vs a
traditional GNU toolchain based one).

>In any case, ChromeOS's DT_RELR use does show that it is de facto a different
>ABI, it is only unfortunate that its ELF ABI does not give us any standard
>marking to advertise so (and we will need to resort on some hacking such as
>scanning for some symbol or versioning to to do).
>
>I am not sure if we should really care to handle such situations, it would
>be nice if we can coordinate with ChromeOS to get it align its ABI with
>mainstream and sort DT_RELR but I think *now* it is not a requisite and I
>think we should move DT_RELR support independently.

Like every glibc Linux distribution carrying some glibc patches which
may decrease binary compatibility with other glibc Linux distributions,
ChromeOS carries some patches like RELR, Disable-float128, and
add-clang-style-FORTIFY patches. (I've heard about complaints about the
latter two patches, they are Clang oriented and will likely benefit
glibc-build-with-clang gets more love:
https://maskray.me/blog/2021-10-10-when-can-glibc-be-built-with-clang)

If you'd like to discuss with them to minimize ABI differences, they
will be happy to have a better communication with the upstream (and, the
software repository and code review website are all open).
Different Linux distributions have different priorities and focus.

For RELR, my suggestion is:

* add the DT_RELR patch without lockout to glibc 2.35
* if some distributions are really fond of "time travel compatibility",
   develop the lockout mechanism (in 2.36 or 2.37)
* add GNU ld support
* After a long time, add a know to GCC to pass the glibc oriented option to ld
* I'll likely not add a lackout mechanism to ld.lld --pack-dyn-relocs.
* After many years, make GCC default to the RELR linker option.