[PATCH v6 3/5] Add GLIBC_ABI_DT_RELR for DT_RELR support

[H.J. Lu]

Does the linker add the version dependency? Does ld.so support DT_RELR?

On Wed, Mar 30, 2022, 10:17 AM Adhemerval Zanella <
adhemerval.zanella@linaro.org> wrote:

>
>
> On 30/03/2022 11:41, H.J. Lu wrote:
> > On Wed, Mar 30, 2022 at 7:18 AM Adhemerval Zanella
> > <adhemerval.zanella@linaro.org> wrote:
> >>
> >>
> >>
> >> On 29/03/2022 19:29, H.J. Lu wrote:
> >>> On Tue, Mar 29, 2022 at 9:52 AM Adhemerval Zanella
> >>> <adhemerval.zanella@linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 10/03/2022 17:03, H.J. Lu via Libc-alpha wrote:
> >>>>> The EI_ABIVERSION field of the ELF header in executables and shared
> >>>>> libraries can be bumped to indicate the minimum ABI requirement on
> the
> >>>>> dynamic linker.  However, EI_ABIVERSION in executables isn't checked
> by
> >>>>> the Linux kernel ELF loader nor the existing dynamic linker.
> Executables
> >>>>> will crash mysteriously if the dynamic linker doesn't support the ABI
> >>>>> features required by the EI_ABIVERSION field.  The dynamic linker
> should
> >>>>> be changed to check EI_ABIVERSION in executables.
> >>>>>
> >>>>> Add a glibc version, GLIBC_ABI_DT_RELR, to indicate DT_RELR support
> so
> >>>>> that the existing dynamic linkers will issue an error on executables
> with
> >>>>> GLIBC_ABI_DT_RELR dependency.  Issue an error if there is a DT_RELR
> entry
> >>>>> without GLIBC_ABI_DT_RELR dependency nor GLIBC_PRIVATE definition.
> >>>>>
> >>>>> Support __placeholder_only_for_empty_version_map as the placeholder
> symbol
> >>>>> used only for empty version map to generate GLIBC_ABI_DT_RELR
> without any
> >>>>> symbols.
> >>>>
> >>>> I think it only make sense to add the GLIBC_ABI_DT_RELR if the ABI
> actually
> >>>> supports DT_RELR, otherwise if the ABI start to support old glibcs
> might
> >>>> wrongly assumes DT_RELR and fails with undefined behavior at runtime
> >>>> (which this patch essentially tries to avoid).
> >>>
> >>> The DT_RELR set enables DT_RELR in glibc for all targets.
> >> If I understood correctly, if we add GLIBC_ABI_DT_RELR on 2.36 but only
> enable
> >> it on some architecture on 2.37 and try to run a binary with DT_RELR
> enabled
> >> on glibc 2.36, _dl_check_map_versions won't accuse a failure and it will
> >> eventually only fail at runtime (since relocation won't be applied).  My
> >> understanding we are trying to avoid such failures.
> >
> > My patch set enables DT_RELR and GLIBC_ABI_DT_RELR on glibc 2.36
> > for all, regardless of binutils version.   There is no per-arch
> > behavior.    Only
> > DT_RELR run-time tests are enabled for linkers with -z
> pack-relative-relocs.
>
> But it still does not fail when the architecture does not actually
> implement
> RELR even when static linker does:
>
> $ clang --target=aarch64-linux-gnu -fuse-ld=lld
> -Wl,-z,pack-relative-relocs -fpie -o test -pie test.c
> $ aarch64-glibc-linux-gnu-readelf -S test | grep relr\.dyn
>   [ 9] .relr.dyn         RELR             0000000000000528  00000528
> $ ./elf/ld.so --library-path . ./test
> $
>
> I would expect that even when binary adds GLIBC_ABI_DT_RELR, if dynamic
> linker
> does not have DT_RELR it would fail early.
>
>