Message ID | 20211119152655.121201-1-hjl.tools@gmail.com |
---|---|
State | New |
Headers | show |
Series | Add GLIBC_PRIVATE_RELR as proxy for DT_RELR | expand |
* H. J. Lu: > Executables with DT_RELR will crash mysteriously with glibc binaries > without DT_RELR support. Bump EI_ABIVERSION won't prevent crash since > the Linux kernel loader doesn't check EI_ABIVERSION on executables. > Adding a glibc version dependency on the first glibc version with > DT_RELR support will prevent backporting DT_RELR support to released > glibc branches. > > Add a GLIBC_PRIVATE_RELR version as a proxy for DT_RELR support in glibc. > Linker should add the GLIBC_PRIVATE_RELR version dependency on binaries > with DT_RELR. GLIBC_PRIVATE_RELR should be backported together when > backporting DT_RELR support. I don't like it. What's wrong about EI_ABIVERSION? The kernel doesn't need to check EI_ABIVERSION because it does not do relocation processing. Thanks, Florian
On Fri, Nov 19, 2021 at 7:30 AM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > Executables with DT_RELR will crash mysteriously with glibc binaries > > without DT_RELR support. Bump EI_ABIVERSION won't prevent crash since > > the Linux kernel loader doesn't check EI_ABIVERSION on executables. > > Adding a glibc version dependency on the first glibc version with > > DT_RELR support will prevent backporting DT_RELR support to released > > glibc branches. > > > > Add a GLIBC_PRIVATE_RELR version as a proxy for DT_RELR support in glibc. > > Linker should add the GLIBC_PRIVATE_RELR version dependency on binaries > > with DT_RELR. GLIBC_PRIVATE_RELR should be backported together when > > backporting DT_RELR support. > > I don't like it. What's wrong about EI_ABIVERSION? Bumping EI_ABIVERSION on executables doesn't prevent crashes with existing ld.so binaries. > The kernel doesn't need to check EI_ABIVERSION because it does not do > relocation processing. > > Thanks, > Florian >
* H. J. Lu: > On Fri, Nov 19, 2021 at 7:30 AM Florian Weimer <fweimer@redhat.com> wrote: >> >> * H. J. Lu: >> >> > Executables with DT_RELR will crash mysteriously with glibc binaries >> > without DT_RELR support. Bump EI_ABIVERSION won't prevent crash since >> > the Linux kernel loader doesn't check EI_ABIVERSION on executables. >> > Adding a glibc version dependency on the first glibc version with >> > DT_RELR support will prevent backporting DT_RELR support to released >> > glibc branches. >> > >> > Add a GLIBC_PRIVATE_RELR version as a proxy for DT_RELR support in glibc. >> > Linker should add the GLIBC_PRIVATE_RELR version dependency on binaries >> > with DT_RELR. GLIBC_PRIVATE_RELR should be backported together when >> > backporting DT_RELR support. >> >> I don't like it. What's wrong about EI_ABIVERSION? > > Bumping EI_ABIVERSION on executables doesn't prevent crashes > with existing ld.so binaries. Oh, right, I keep forgetting that. If we do not intend to backport features that require an EI_ABIVERSION bump back further than glibc 2.34, we can rely on the __libc_start_main switch to the GLIBC_2.34 symbol version. Thanks, Florian
On Fri, Nov 19, 2021 at 2:47 PM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > On Fri, Nov 19, 2021 at 7:30 AM Florian Weimer <fweimer@redhat.com> wrote: > >> > >> * H. J. Lu: > >> > >> > Executables with DT_RELR will crash mysteriously with glibc binaries > >> > without DT_RELR support. Bump EI_ABIVERSION won't prevent crash since > >> > the Linux kernel loader doesn't check EI_ABIVERSION on executables. > >> > Adding a glibc version dependency on the first glibc version with > >> > DT_RELR support will prevent backporting DT_RELR support to released > >> > glibc branches. > >> > > >> > Add a GLIBC_PRIVATE_RELR version as a proxy for DT_RELR support in glibc. > >> > Linker should add the GLIBC_PRIVATE_RELR version dependency on binaries > >> > with DT_RELR. GLIBC_PRIVATE_RELR should be backported together when > >> > backporting DT_RELR support. > >> > >> I don't like it. What's wrong about EI_ABIVERSION? > > > > Bumping EI_ABIVERSION on executables doesn't prevent crashes > > with existing ld.so binaries. > > Oh, right, I keep forgetting that. What is wrong with GLIBC_PRIVATE_RELR? > If we do not intend to backport features that require an EI_ABIVERSION > bump back further than glibc 2.34, we can rely on the __libc_start_main > switch to the GLIBC_2.34 symbol version. > GLIBC_2.34 is no better than GLIBC_PRIVATE_RELR.
On Fri, 19 Nov 2021, H.J. Lu via Libc-alpha wrote:
> What is wrong with GLIBC_PRIVATE_RELR?
We shouldn't have any GLIBC_PRIVATE* references in normal user binaries
built with glibc; GLIBC_PRIVATE* should be considered a namespace limited
to internal use between the various binaries built by glibc, and with no
ABI stability requirements.
diff --git a/io/Versions b/io/Versions index 4e19540885..629d458324 100644 --- a/io/Versions +++ b/io/Versions @@ -141,7 +141,6 @@ libc { closefrom; } GLIBC_PRIVATE { - __libc_fcntl64; __fcntl_nocancel; __open64_nocancel; __write_nocancel; @@ -151,4 +150,7 @@ libc { __file_change_detection_for_fp; __fstat64; } + GLIBC_PRIVATE_RELR { + __libc_fcntl64; + } } diff --git a/scripts/abilist.awk b/scripts/abilist.awk index 24a34ccbed..620aacb627 100644 --- a/scripts/abilist.awk +++ b/scripts/abilist.awk @@ -55,7 +55,7 @@ $2 == "g" || $2 == "w" && (NF == 7 || NF == 8) { # caused STV_HIDDEN symbols to appear in .dynsym, though that is useless. if (NF > 7 && $7 == ".hidden") next; - if (version == "GLIBC_PRIVATE" && !include_private) next; + if (version ~ /^GLIBC_PRIVATE/ && !include_private) next; desc = ""; if (type == "D" && ($4 == ".tbss" || $4 == ".tdata")) {