Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

["H.J. Lu" <hjl.tools@gmail.com>]

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.