* RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED @ 2021-10-26 14:53 H.J. Lu 2021-10-26 15:25 ` Florian Weimer 0 siblings, 1 reply; 11+ messages in thread From: H.J. Lu @ 2021-10-26 14:53 UTC (permalink / raw) To: GNU C Library, binutils /* The needed glibc 2 minor version property for the object file. */ #define GNU_PROPERTY_1_GLIBC_2_NEEDED (GNU_PROPERTY_UINT32_OR_LO + 1) /* The needed glibc 2 minor base version. */ #define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE 35 /* Set if the object file requires glibc 2 minor version M. */ #define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION(m) \ (1U << ((m) - GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE)) Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to DT_VERNEED. It can be used to embed glibc version dependency in .o files: [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n x.o Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA used: x86 feature used: x86 [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n glibc-2-minor-1.o Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: 1_glibc_2_needed: 2.35, 2.38 GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA used: x86 feature used: x86 [hjl@gnu-cfl-2 elfvers-1]$ make x gcc -B./ -o x x.o glibc-2-minor-1.o [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x Version symbols section '.gnu.version' contains 4 entries: Addr: 0x00000000004004ae Offset: 0x0004ae Link: 6 (.dynsym) 000: 0 (*local*) 2 (GLIBC_2.34) 3 (GLIBC_2.2.5) 1 (*global*) Version needs section '.gnu.version_r' contains 1 entry: Addr: 0x00000000004004b8 Offset: 0x0004b8 Link: 7 (.dynstr) 000000: Version: 1 File: libc.so.6 Cnt: 4 0x0010: Name: GLIBC_2.38 Flags: none Version: 5 0x0020: Name: GLIBC_2.35 Flags: none Version: 4 0x0030: Name: GLIBC_2.2.5 Flags: none Version: 3 0x0040: Name: GLIBC_2.34 Flags: none Version: 2 Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000040 NT_GNU_PROPERTY_TYPE_0 Properties: 1_glibc_2_needed: 2.35, 2.38 ... [hjl@gnu-cfl-2 elfvers-1]$ ./x ./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x) ./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x) [hjl@gnu-cfl-2 elfvers-1]$ H.J. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-26 14:53 RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED H.J. Lu @ 2021-10-26 15:25 ` Florian Weimer 2021-10-26 15:51 ` H.J. Lu 0 siblings, 1 reply; 11+ messages in thread From: Florian Weimer @ 2021-10-26 15:25 UTC (permalink / raw) To: H.J. Lu via Libc-alpha; +Cc: binutils, H.J. Lu * H. J. Lu via Libc-alpha: > [hjl@gnu-cfl-2 elfvers-1]$ make x > gcc -B./ -o x x.o glibc-2-minor-1.o > [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x > Version symbols section '.gnu.version' contains 4 entries: > Addr: 0x00000000004004ae Offset: 0x0004ae Link: 6 (.dynsym) > 000: 0 (*local*) 2 (GLIBC_2.34) 3 (GLIBC_2.2.5) 1 (*global*) > > Version needs section '.gnu.version_r' contains 1 entry: > Addr: 0x00000000004004b8 Offset: 0x0004b8 Link: 7 (.dynstr) > 000000: Version: 1 File: libc.so.6 Cnt: 4 > 0x0010: Name: GLIBC_2.38 Flags: none Version: 5 > 0x0020: Name: GLIBC_2.35 Flags: none Version: 4 > 0x0030: Name: GLIBC_2.2.5 Flags: none Version: 3 > 0x0040: Name: GLIBC_2.34 Flags: none Version: 2 > > Displaying notes found in: .note.gnu.property > Owner Data size Description > GNU 0x00000040 NT_GNU_PROPERTY_TYPE_0 > Properties: 1_glibc_2_needed: 2.35, 2.38 > ... > [hjl@gnu-cfl-2 elfvers-1]$ ./x > ./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x) > ./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x) > [hjl@gnu-cfl-2 elfvers-1]$ What's the intended use case? This proposal may conflict in spirit with the glibc proposal to support preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 to a glibc 2.28 installation, for example). So far, symbol versions have only been used as a quick check for ABI coverage that also works with lazy binding. This doesn't look the right mechanism to me without also bringing in new marker symbols, in which case the note is not needed. The problem that linkers and loaders ignore unknown types should be tackled in a different way, e.g. by flagging critical types in some way. See: Critical program headers and dynamic tags <https://groups.google.com/g/generic-abi/c/vdG_G4l3N-Y/m/SB3DurdbBAAJ> Thanks, Florian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-26 15:25 ` Florian Weimer @ 2021-10-26 15:51 ` H.J. Lu 2021-10-26 18:39 ` v2: " H.J. Lu 2021-10-28 6:55 ` Florian Weimer 0 siblings, 2 replies; 11+ messages in thread From: H.J. Lu @ 2021-10-26 15:51 UTC (permalink / raw) To: Florian Weimer; +Cc: H.J. Lu via Libc-alpha, Binutils On Tue, Oct 26, 2021 at 8:26 AM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu via Libc-alpha: > > > [hjl@gnu-cfl-2 elfvers-1]$ make x > > gcc -B./ -o x x.o glibc-2-minor-1.o > > [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x > > Version symbols section '.gnu.version' contains 4 entries: > > Addr: 0x00000000004004ae Offset: 0x0004ae Link: 6 (.dynsym) > > 000: 0 (*local*) 2 (GLIBC_2.34) 3 (GLIBC_2.2.5) 1 (*global*) > > > > Version needs section '.gnu.version_r' contains 1 entry: > > Addr: 0x00000000004004b8 Offset: 0x0004b8 Link: 7 (.dynstr) > > 000000: Version: 1 File: libc.so.6 Cnt: 4 > > 0x0010: Name: GLIBC_2.38 Flags: none Version: 5 > > 0x0020: Name: GLIBC_2.35 Flags: none Version: 4 > > 0x0030: Name: GLIBC_2.2.5 Flags: none Version: 3 > > 0x0040: Name: GLIBC_2.34 Flags: none Version: 2 > > > > Displaying notes found in: .note.gnu.property > > Owner Data size Description > > GNU 0x00000040 NT_GNU_PROPERTY_TYPE_0 > > Properties: 1_glibc_2_needed: 2.35, 2.38 > > ... > > [hjl@gnu-cfl-2 elfvers-1]$ ./x > > ./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x) > > ./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x) > > [hjl@gnu-cfl-2 elfvers-1]$ > > What's the intended use case? The intended use case is to add a glibc version dependency without referencing any symbols for the glibc version. > This proposal may conflict in spirit with the glibc proposal to support > preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 > to a glibc 2.28 installation, for example). So far, symbol versions Why will adding a glibc version dependency change the preload behavior? > have only been used as a quick check for ABI coverage that also works > with lazy binding. This doesn't look the right mechanism to me without > also bringing in new marker symbols, in which case the note is not > needed. The GNU_PROPERTY_1_GLIBC_2_NEEDED note can be removed from shared libraries and executables. > > The problem that linkers and loaders ignore unknown types should be > tackled in a different way, e.g. by flagging critical types in some way. > See: > > Critical program headers and dynamic tags > <https://groups.google.com/g/generic-abi/c/vdG_G4l3N-Y/m/SB3DurdbBAAJ> > This won't help the existing ld.so binaries which this proposal is addressing. -- H.J. ^ permalink raw reply [flat|nested] 11+ messages in thread
* v2: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-26 15:51 ` H.J. Lu @ 2021-10-26 18:39 ` H.J. Lu 2021-10-28 6:55 ` Florian Weimer 1 sibling, 0 replies; 11+ messages in thread From: H.J. Lu @ 2021-10-26 18:39 UTC (permalink / raw) To: Florian Weimer; +Cc: H.J. Lu via Libc-alpha, Binutils Here is the v2 proposal. -- H.J. -- Motivations: 1. Some binaries which require new ELF features, like DT_RELR, only work with the new glibc binary. They crash at run-time with the older glibc binaries. 2. Somes binaries compiled with the new language features, like C2X printf specifiers, only generate correct results with the new glibc binary. Since we don't add new glibc versions to the printf function family, they generate incorrect results at run-time with the older glibc binaries. Here is a proposal to encode glibc version dependencies in relocatable objects: /* The needed glibc 2 minor version property for the object file. */ #define GNU_PROPERTY_1_GLIBC_2_NEEDED (GNU_PROPERTY_UINT32_OR_LO + 1) /* The needed glibc 2 minor base version. */ #define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE 35 /* Set if the object file requires glibc 2 minor version M. */ #define GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_VERSION(m) \ (1U << ((m) - GNU_PROPERTY_1_GLIBC_2_NEEDED_MINOR_BASE)) Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note when generating shared libraries and executables. [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n x.o Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA used: x86 feature used: x86 [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n glibc-2-minor-1.o Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: 1_glibc_2_needed: 2.35, 2.38 GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA used: x86 feature used: x86 [hjl@gnu-cfl-2 elfvers-1]$ make x gcc -B./ -o x x.o glibc-2-minor-1.o [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x Version symbols section '.gnu.version' contains 4 entries: Addr: 0x00000000004004ae Offset: 0x0004ae Link: 6 (.dynsym) 000: 0 (*local*) 2 (GLIBC_2.34) 3 (GLIBC_2.2.5) 1 (*global*) Version needs section '.gnu.version_r' contains 1 entry: Addr: 0x00000000004004b8 Offset: 0x0004b8 Link: 7 (.dynstr) 000000: Version: 1 File: libc.so.6 Cnt: 4 0x0010: Name: GLIBC_2.38 Flags: none Version: 5 0x0020: Name: GLIBC_2.35 Flags: none Version: 4 0x0030: Name: GLIBC_2.2.5 Flags: none Version: 3 0x0040: Name: GLIBC_2.34 Flags: none Version: 2 ... [hjl@gnu-cfl-2 elfvers-1]$ ./x ./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x) ./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x) [hjl@gnu-cfl-2 elfvers-1]$ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-26 15:51 ` H.J. Lu 2021-10-26 18:39 ` v2: " H.J. Lu @ 2021-10-28 6:55 ` Florian Weimer 2021-10-28 13:37 ` H.J. Lu 1 sibling, 1 reply; 11+ messages in thread From: Florian Weimer @ 2021-10-28 6:55 UTC (permalink / raw) To: H.J. Lu; +Cc: H.J. Lu via Libc-alpha, Binutils * H. J. Lu: >> This proposal may conflict in spirit with the glibc proposal to support >> preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 >> to a glibc 2.28 installation, for example). So far, symbol versions > > Why will adding a glibc version dependency change the preload > behavior? Previously, we thought we could relax the version coverage check to enable adding completely new symbol versions by preloading an implementation. With BIND_NOW, this is completely safe because missing symbols are still detected. But this turns unreliable once glibc versions are tied to ELF implementation features. Preloading an implementation of _dl_find_eh_frame@GLIBC_2.35 (for example) will not add dynamic linker features first implemented in glibc 2.35. >> The problem that linkers and loaders ignore unknown types should be >> tackled in a different way, e.g. by flagging critical types in some way. >> See: >> >> Critical program headers and dynamic tags >> <https://groups.google.com/g/generic-abi/c/vdG_G4l3N-Y/m/SB3DurdbBAAJ> >> > > This won't help the existing ld.so binaries which this proposal > is addressing. We need to increase the ABI version once, to signal the requirement for critical tags checking. Thanks, Florian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-28 6:55 ` Florian Weimer @ 2021-10-28 13:37 ` H.J. Lu 2021-10-28 14:08 ` Florian Weimer 2021-10-29 12:47 ` Michael Matz 0 siblings, 2 replies; 11+ messages in thread From: H.J. Lu @ 2021-10-28 13:37 UTC (permalink / raw) To: Florian Weimer; +Cc: H.J. Lu via Libc-alpha, Binutils On Wed, Oct 27, 2021 at 11:55 PM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > >> This proposal may conflict in spirit with the glibc proposal to support > >> preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 > >> to a glibc 2.28 installation, for example). So far, symbol versions > > > > Why will adding a glibc version dependency change the preload > > behavior? > > Previously, we thought we could relax the version coverage check to > enable adding completely new symbol versions by preloading an > implementation. With BIND_NOW, this is completely safe because missing > symbols are still detected. But this turns unreliable once glibc > versions are tied to ELF implementation features. Preloading an > implementation of _dl_find_eh_frame@GLIBC_2.35 (for example) will not > add dynamic linker features first implemented in glibc 2.35. I am not sure if I am following your concerns. We have an ELF feature, like DT_RELR, which is tied to a glibc version. The binary with DT_RELR will crash with the older glibcs. And you DON'T want such a binary with a dependency on the required glibc version. Can you tell me why? > >> The problem that linkers and loaders ignore unknown types should be > >> tackled in a different way, e.g. by flagging critical types in some way. > >> See: > >> > >> Critical program headers and dynamic tags > >> <https://groups.google.com/g/generic-abi/c/vdG_G4l3N-Y/m/SB3DurdbBAAJ> > >> > > > > This won't help the existing ld.so binaries which this proposal > > is addressing. > > We need to increase the ABI version once, to signal the requirement for > critical tags checking. > Which ABI version? .note.ABI-tag or EI_ABIVERSION? A binary linked against glibc 2.40 without DT_RELR can run with glibc 2.34. But a binary linked against glibc 2.30 with DT_RELR won't run with glibc 2.34 at all. Increasing the ABI version doesn't solve the DT_RELR issue. -- H.J. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-28 13:37 ` H.J. Lu @ 2021-10-28 14:08 ` Florian Weimer 2021-10-28 14:17 ` H.J. Lu 2021-10-29 12:47 ` Michael Matz 1 sibling, 1 reply; 11+ messages in thread From: Florian Weimer @ 2021-10-28 14:08 UTC (permalink / raw) To: H.J. Lu; +Cc: H.J. Lu via Libc-alpha, Binutils * H. J. Lu: > I am not sure if I am following your concerns. We have an ELF feature, > like DT_RELR, which is tied to a glibc version. The binary with DT_RELR > will crash with the older glibcs. And you DON'T want such a binary with > a dependency on the required glibc version. Can you tell me why? Historically, such features have not been tied to a glibc version. CET, DT_AUDIT, AArch64 variant PCS support, nearly arbitrary calling convention support on x86-64 all are not really version-specific (they have been backported to varying degrees), and those involve dynamic linker features. In contrast, if DT_RELR support is indicated by a GLIBC_2.35 version dependency, it is necessary to backport all of the GLIBC_2.35 symbol set as part of the DT_RELR backport. This means such backports are usually not feasible. >> >> The problem that linkers and loaders ignore unknown types should be >> >> tackled in a different way, e.g. by flagging critical types in some way. >> >> See: >> >> >> >> Critical program headers and dynamic tags >> >> <https://groups.google.com/g/generic-abi/c/vdG_G4l3N-Y/m/SB3DurdbBAAJ> >> >> >> > >> > This won't help the existing ld.so binaries which this proposal >> > is addressing. >> >> We need to increase the ABI version once, to signal the requirement for >> critical tags checking. >> > > Which ABI version? .note.ABI-tag or EI_ABIVERSION? A binary linked > against glibc 2.40 without DT_RELR can run with glibc 2.34. But a binary > linked against glibc 2.30 with DT_RELR won't run with glibc 2.34 at all. > Increasing the ABI version doesn't solve the DT_RELR issue. The way EI_ABIVERSION works is that the link editor produces the minimum version needed by the features in the binary. So if the link editor DT_RELR, it would produce a DT_CRITICAL_DT tag for DT_RELR and set EI_ABIVERSION for critical DT tag support. Similar for other critical DT Tags. If no critical DT tags are used, an earlier EI_ABIVERSION can be used. Thanks, Florian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-28 14:08 ` Florian Weimer @ 2021-10-28 14:17 ` H.J. Lu 2021-10-28 14:20 ` H.J. Lu 0 siblings, 1 reply; 11+ messages in thread From: H.J. Lu @ 2021-10-28 14:17 UTC (permalink / raw) To: Florian Weimer; +Cc: H.J. Lu via Libc-alpha, Binutils On Thu, Oct 28, 2021 at 7:08 AM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > I am not sure if I am following your concerns. We have an ELF feature, > > like DT_RELR, which is tied to a glibc version. The binary with DT_RELR > > will crash with the older glibcs. And you DON'T want such a binary with > > a dependency on the required glibc version. Can you tell me why? > > Historically, such features have not been tied to a glibc version. CET, > DT_AUDIT, AArch64 variant PCS support, nearly arbitrary calling > convention support on x86-64 all are not really version-specific (they > have been backported to varying degrees), and those involve dynamic > linker features. > > In contrast, if DT_RELR support is indicated by a GLIBC_2.35 version > dependency, it is necessary to backport all of the GLIBC_2.35 symbol set > as part of the DT_RELR backport. This means such backports are usually > not feasible. So you would like to backport DT_RELR. > >> >> The problem that linkers and loaders ignore unknown types should be > >> >> tackled in a different way, e.g. by flagging critical types in some way. > >> >> See: > >> >> > >> >> Critical program headers and dynamic tags > >> >> <https://groups.google.com/g/generic-abi/c/vdG_G4l3N-Y/m/SB3DurdbBAAJ> > >> >> > >> > > >> > This won't help the existing ld.so binaries which this proposal > >> > is addressing. > >> > >> We need to increase the ABI version once, to signal the requirement for > >> critical tags checking. > >> > > > > Which ABI version? .note.ABI-tag or EI_ABIVERSION? A binary linked > > against glibc 2.40 without DT_RELR can run with glibc 2.34. But a binary > > linked against glibc 2.30 with DT_RELR won't run with glibc 2.34 at all. > > Increasing the ABI version doesn't solve the DT_RELR issue. > > The way EI_ABIVERSION works is that the link editor produces the minimum > version needed by the features in the binary. > > So if the link editor DT_RELR, it would produce a DT_CRITICAL_DT tag for > DT_RELR and set EI_ABIVERSION for critical DT tag support. Similar for > other critical DT Tags. If no critical DT tags are used, an earlier > EI_ABIVERSION can be used. > There is no DT_CRITICAL_DT support in the older glibcs. The only option is EI_ABIVERSION and I don't think we need DT_CRITICAL_DT. We update EI_ABIVERSION whenever there is a new feature added. I think it is one missing piece in the original DT_RELR proposal. -- H.J. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-28 14:17 ` H.J. Lu @ 2021-10-28 14:20 ` H.J. Lu 2021-10-29 18:11 ` Florian Weimer 0 siblings, 1 reply; 11+ messages in thread From: H.J. Lu @ 2021-10-28 14:20 UTC (permalink / raw) To: Florian Weimer; +Cc: H.J. Lu via Libc-alpha, Binutils On Thu, Oct 28, 2021 at 7:17 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Thu, Oct 28, 2021 at 7:08 AM Florian Weimer <fweimer@redhat.com> wrote: > > > > * H. J. Lu: > > > > > I am not sure if I am following your concerns. We have an ELF feature, > > > like DT_RELR, which is tied to a glibc version. The binary with DT_RELR > > > will crash with the older glibcs. And you DON'T want such a binary with > > > a dependency on the required glibc version. Can you tell me why? > > > > Historically, such features have not been tied to a glibc version. CET, > > DT_AUDIT, AArch64 variant PCS support, nearly arbitrary calling > > convention support on x86-64 all are not really version-specific (they > > have been backported to varying degrees), and those involve dynamic > > linker features. > > > > In contrast, if DT_RELR support is indicated by a GLIBC_2.35 version > > dependency, it is necessary to backport all of the GLIBC_2.35 symbol set > > as part of the DT_RELR backport. This means such backports are usually > > not feasible. > > So you would like to backport DT_RELR. > > > >> >> The problem that linkers and loaders ignore unknown types should be > > >> >> tackled in a different way, e.g. by flagging critical types in some way. > > >> >> See: > > >> >> > > >> >> Critical program headers and dynamic tags > > >> >> <https://groups.google.com/g/generic-abi/c/vdG_G4l3N-Y/m/SB3DurdbBAAJ> > > >> >> > > >> > > > >> > This won't help the existing ld.so binaries which this proposal > > >> > is addressing. > > >> > > >> We need to increase the ABI version once, to signal the requirement for > > >> critical tags checking. > > >> > > > > > > Which ABI version? .note.ABI-tag or EI_ABIVERSION? A binary linked > > > against glibc 2.40 without DT_RELR can run with glibc 2.34. But a binary > > > linked against glibc 2.30 with DT_RELR won't run with glibc 2.34 at all. > > > Increasing the ABI version doesn't solve the DT_RELR issue. > > > > The way EI_ABIVERSION works is that the link editor produces the minimum > > version needed by the features in the binary. > > > > So if the link editor DT_RELR, it would produce a DT_CRITICAL_DT tag for > > DT_RELR and set EI_ABIVERSION for critical DT tag support. Similar for > > other critical DT Tags. If no critical DT tags are used, an earlier > > EI_ABIVERSION can be used. > > > > There is no DT_CRITICAL_DT support in the older glibcs. The only option > is EI_ABIVERSION and I don't think we need DT_CRITICAL_DT. We update > EI_ABIVERSION whenever there is a new feature added. I think it is one > missing piece in the original DT_RELR proposal. > How do we deal with Somes binaries compiled with the new language features, like C2X printf specifiers, only generate correct results with the new glibc binary. Since we don't add new glibc versions to the printf function family, they generate incorrect results at run-time with the older glibc binaries. -- H.J. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-28 14:20 ` H.J. Lu @ 2021-10-29 18:11 ` Florian Weimer 0 siblings, 0 replies; 11+ messages in thread From: Florian Weimer @ 2021-10-29 18:11 UTC (permalink / raw) To: H.J. Lu; +Cc: H.J. Lu via Libc-alpha, Binutils * H. J. Lu: > How do we deal with > > Somes binaries compiled with the new language features, like C2X > printf specifiers, only generate correct results with the new glibc > binary. Since we don't add new glibc versions to the printf function > family, they generate incorrect results at run-time with the older > glibc binaries. We decided not to use symbol versions for that. Likewise for support for new flags in e.g. dlopen. We also do not od this for system calls and system call flags. If an application uses the new printf specifiers, it can probe for support at run time and register its own implementation if necessary. This is a bit complicated, but it's how applications are expected to handle new flags in older interfaces. Thanks, Florian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED 2021-10-28 13:37 ` H.J. Lu 2021-10-28 14:08 ` Florian Weimer @ 2021-10-29 12:47 ` Michael Matz 1 sibling, 0 replies; 11+ messages in thread From: Michael Matz @ 2021-10-29 12:47 UTC (permalink / raw) To: H.J. Lu; +Cc: Florian Weimer, H.J. Lu via Libc-alpha, Binutils Hello, On Thu, 28 Oct 2021, H.J. Lu via Binutils wrote: > > >> This proposal may conflict in spirit with the glibc proposal to support > > >> preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 > > >> to a glibc 2.28 installation, for example). So far, symbol versions > > > > > > Why will adding a glibc version dependency change the preload > > > behavior? > > > > Previously, we thought we could relax the version coverage check to > > enable adding completely new symbol versions by preloading an > > implementation. With BIND_NOW, this is completely safe because missing > > symbols are still detected. But this turns unreliable once glibc > > versions are tied to ELF implementation features. Preloading an > > implementation of _dl_find_eh_frame@GLIBC_2.35 (for example) will not > > add dynamic linker features first implemented in glibc 2.35. > > I am not sure if I am following your concerns. We have an ELF feature, > like DT_RELR, which is tied to a glibc version. The binary with DT_RELR > will crash with the older glibcs. And you DON'T want such a binary with > a dependency on the required glibc version. Can you tell me why? You never want to test for versions to imply absence or presence of features. You want to test for the feature, or alternatively for an indication of said feature. Such indication could be the existence of a fake symbol (which can have a symbol version, no less), some flag mechanism (where to-be-defined flags would mean features), or suchlike. I find the idea of symbols the most intuitive one. DT_RELR binaries could require (from their .dynsym), say '_dl_have_relr', and glibc supporting it would provide that feature. Version checks always run into trouble vs. backports, and simply aren't the right tool. Ciao, Michael. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-10-29 18:11 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-26 14:53 RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED H.J. Lu 2021-10-26 15:25 ` Florian Weimer 2021-10-26 15:51 ` H.J. Lu 2021-10-26 18:39 ` v2: " H.J. Lu 2021-10-28 6:55 ` Florian Weimer 2021-10-28 13:37 ` H.J. Lu 2021-10-28 14:08 ` Florian Weimer 2021-10-28 14:17 ` H.J. Lu 2021-10-28 14:20 ` H.J. Lu 2021-10-29 18:11 ` Florian Weimer 2021-10-29 12:47 ` Michael Matz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).