Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

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

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.