[PATCH v5 0/5] Support DT_RELR relative relocation format

Fangrui Song maskray@google.com
Thu Mar 3 07:10:30 GMT 2022


On 2022-03-02, H.J. Lu wrote:
>Changes in v5:
>
>1. Update NEWS entry with the linker option, -z pack-relative-relocs.
>2. Remove elf/libc-abi-version.exp and use $(READELF) to check
>GLIBC_ABI_DT_RELR.
>
>Changes in v4:
>
>1. Always enable GLIBC_ABI_DT_RELR check.
>2. Use $(OBJDUMP) instead of $(NM) for GLIBC_ABI_DT_RELR check.
>
>Changes in v3:
>
>1. Don't define SUPPORT_DT_RELR.
>2. Enable DT_RELR in glibc shared libraries and position independent
>executables (PIE) automatically if linker supports -z pack-relative-relocs.
>
>Changes in v2:
>
>1. Enable DT_RELR for all targets.
>2. Issue an error if there is a DT_RELR entry without GLIBC_ABI_DT_RELR
>dependency nor GLIBC_PRIVATE definition.
>
>---
>PIE and shared objects usually have many relative relocations. In
>2017/2018, SHT_RELR/DT_RELR was proposed on
>https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/GxjM0L-PBAAJ
>("Proposal for a new section type SHT_RELR") and is a pre-standard. RELR
>usually takes 3% or smaller space than R_*_RELATIVE relocations. The
>virtual memory size of a mostly statically linked PIE is typically 5~10%
>smaller.
>
>Binutils 2.38 supports DT_RELR on x86 with the -z report-relative-reloc
>option.  When DT_RELR is enabled, ld adds a GLIBC_ABI_DT_RELR symbol
>version dependency on libc.so to outputs.  Issue an error if there is a
>DT_RELR entry without GLIBC_ABI_DT_RELR dependency nor GLIBC_PRIVATE
>definition.
>
>DT_RELR is enabled in glibc shared libraries and position independent
>executables (PIE) automatically if linker supports -z pack-relative-relocs.
>
>The DT_RELR usage in glibc can be disabled with --disable-default-dt-relr.
>
>Tested with binutils 2.38 on i686, x86-64 and x32.
>
>
>Fangrui Song (1):
>  elf: Support DT_RELR relative relocation format [BZ #27924]
>
>H.J. Lu (4):
>  elf: Properly handle zero DT_RELA/DT_REL values
>  Add GLIBC_ABI_DT_RELR for DT_RELR support
>  Add --disable-default-dt-relr
>  NEWS: Mention DT_RELR support
>
> INSTALL                |  6 ++++
> Makeconfig             | 19 +++++++++++++
> Makerules              |  2 ++
> NEWS                   |  3 +-
> configure              | 60 +++++++++++++++++++++++++++++++++++++++
> configure.ac           | 23 +++++++++++++++
> elf/Makefile           | 30 ++++++++++++++++++--
> elf/Versions           |  5 ++++
> elf/dl-version.c       | 33 ++++++++++++++++++++--
> elf/dynamic-link.h     | 40 +++++++++++++++++++++++++-
> elf/elf.h              | 13 +++++++--
> elf/get-dynamic-info.h | 19 +++++++++++--
> elf/tst-relr-pie.c     |  1 +
> elf/tst-relr.c         | 64 ++++++++++++++++++++++++++++++++++++++++++
> include/link.h         |  6 ++++
> manual/install.texi    |  5 ++++
> scripts/abilist.awk    |  2 ++
> scripts/versions.awk   |  7 ++++-
> 18 files changed, 325 insertions(+), 13 deletions(-)
> create mode 100644 elf/tst-relr-pie.c
> create mode 100644 elf/tst-relr.c
>
>-- 
>2.35.1
>

Thanks! And thanks for adjusting the objdump/readelf tests to make lld
happy.

Reviewed-by: Fangrui Song <maskray@google.com>

Would be good to check with Joseph, who had some opinions with v1.

I have a new lld with https://reviews.llvm.org/D120701
and have checked that the patch series with (/usr/local/bin/ld == my new
lld) works.

* regular PIE with .relr.dyn work.
* static PIE with .relr.dyn work.



I echo what Peter mentioned in
https://sourceware.org/pipermail/libc-alpha/2022-March/136773.html
See also Gentoo Linux's feedback in a similar line
https://sourceware.org/pipermail/libc-alpha/2021-November/133388.html
I do believe for many distributions this is not so necessary and gives
linkers busywork.

But if this version lockout mechanism is the deal breaker for glibc to
have DT_RELR at all, I am fine with it, for users' good.


More information about the Libc-alpha mailing list