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

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 30/03/2022 14:32, H.J. Lu wrote:
> Does the linker add the version dependency? Does ld.so support DT_RELR?
> 

$ readelf -V test | grep GLIBC_ABI_DT_RELR
  0x0030:   Name: GLIBC_ABI_DT_RELR  Flags: none  Version: 4

But ld.so does not support DT_RELR

$ grep libc_cv_dt_relr config.log 
libc_cv_dt_relr=no


> On Wed, Mar 30, 2022, 10:17 AM Adhemerval Zanella <adhemerval.zanella@linaro.org <mailto: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 <mailto: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 <mailto: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.
>