RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[H.J. Lu]

/* 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.

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[Florian Weimer]

* 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

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[H.J. Lu]

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.

v2: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[H.J. Lu]

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]$

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[Florian Weimer]

* 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

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[H.J. Lu]

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.

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[Florian Weimer]

* 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

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[H.J. Lu]

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.

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[H.J. Lu]

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.

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[Florian Weimer]

* 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

Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[Michael Matz]

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.