[0/7] Support DT_RELR relative relocation format

  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.  The DT_RELR support is enabled
in ld.so only if the linker supports -z report-relative-reloc option.

DT_RELR is enabled in glibc shared libraries and position independent
executables (PIE) automatically if linker supports -z pack-relative-relocs
nd the architecture defines SUPPORT_DT_RELR in config.h.  At the moment,
only x86 targets define SUPPORT_DT_RELR.

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 (6):
  elf: Properly handle zero DT_RELA/DT_REL values
  Add GLIBC_ABI_DT_RELR for DT_RELR support
  x86/configure.ac: Define PI_STATIC_AND_HIDDEN/SUPPORT_STATIC_PIE
  x86: Define SUPPORT_DT_RELR
  Add --disable-default-dt-relr
  NEWS: Mention DT_RELR support

 INSTALL                     |  6 +++
 Makeconfig                  | 19 +++++++++
 Makerules                   |  2 +
 NEWS                        |  5 +++
 config.h.in                 |  6 +++
 configure                   | 84 +++++++++++++++++++++++++++++++++++++
 configure.ac                | 34 +++++++++++++++
 elf/Makefile                | 36 ++++++++++++++--
 elf/Versions                |  7 ++++
 elf/dynamic-link.h          | 40 +++++++++++++++++-
 elf/elf.h                   | 13 +++++-
 elf/get-dynamic-info.h      | 19 +++++++--
 elf/libc-abi-version.exp    |  1 +
 elf/tst-relr-pie.c          |  1 +
 elf/tst-relr.c              | 64 ++++++++++++++++++++++++++++
 manual/install.texi         |  5 +++
 scripts/abilist.awk         |  2 +
 scripts/versions.awk        |  7 +++-
 sysdeps/i386/configure      |  6 ---
 sysdeps/i386/configure.ac   |  7 ----
 sysdeps/x86/configure       |  9 ++++
 sysdeps/x86/configure.ac    | 10 +++++
 sysdeps/x86_64/configure    |  6 ---
 sysdeps/x86_64/configure.ac |  7 ----
 24 files changed, 360 insertions(+), 36 deletions(-)
 create mode 100644 elf/libc-abi-version.exp
 create mode 100644 elf/tst-relr-pie.c
 create mode 100644 elf/tst-relr.c
  

On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote:

> DT_RELR is enabled in glibc shared libraries and position independent
> executables (PIE) automatically if linker supports -z pack-relative-relocs
> nd the architecture defines SUPPORT_DT_RELR in config.h.  At the moment,
> only x86 targets define SUPPORT_DT_RELR.

The patch 1 description says "This patch is simpler than Chrome OS's glibc 
patch and makes ELF_DYNAMIC_DO_RELR available to all ports.".

What exactly would other architectures need to add in glibc to provide 
RELR support, since I don't see any actual architecture-specific code in 
this patch series outside of configure scripts?  Please provide text you 
would propose to add to https://sourceware.org/glibc/wiki/PortStatus that 
gives an architecture maintainer all the information needed to add such 
support for their architecture.  If in fact no architecture-specific code 
should be needed, please remove the SUPPORT_DT_RELR handling and just 
allow glibc to support the feature for all architectures (while using RELR 
in glibc itself for architectures where the linker support is present, as 
detected by a configure test on the linker rather than hardcoding 
information about which architectures have that linker support at a given 
time).

The default should be to support a feature for all architectures.  A patch 
series supporting a feature for only some architectures needs a positive 
reason for excluding other architectures (for example, that each 
architecture needs architecture-specific code, for which you provide 
suitable documentation to add to PortStatus to help architecture 
maintainers in writing such code).
  

On Fri, Feb 4, 2022 at 12:00 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote:
>
> > DT_RELR is enabled in glibc shared libraries and position independent
> > executables (PIE) automatically if linker supports -z pack-relative-relocs
> > nd the architecture defines SUPPORT_DT_RELR in config.h.  At the moment,
> > only x86 targets define SUPPORT_DT_RELR.
>
> The patch 1 description says "This patch is simpler than Chrome OS's glibc
> patch and makes ELF_DYNAMIC_DO_RELR available to all ports.".
>
> What exactly would other architectures need to add in glibc to provide
> RELR support, since I don't see any actual architecture-specific code in

DT_RELR is enabled only if linker supports -z report-relative-reloc option
which adds GLIBC_ABI_DT_RELR dependency in the linker output to
prevent random crashes with the older glibc binaries.

> this patch series outside of configure scripts?  Please provide text you
> would propose to add to https://sourceware.org/glibc/wiki/PortStatus that
> gives an architecture maintainer all the information needed to add such
> support for their architecture.  If in fact no architecture-specific code
> should be needed, please remove the SUPPORT_DT_RELR handling and just
> allow glibc to support the feature for all architectures (while using RELR
> in glibc itself for architectures where the linker support is present, as
> detected by a configure test on the linker rather than hardcoding
> information about which architectures have that linker support at a given
> time).
>
> The default should be to support a feature for all architectures.  A patch
> series supporting a feature for only some architectures needs a positive
> reason for excluding other architectures (for example, that each
> architecture needs architecture-specific code, for which you provide
> suitable documentation to add to PortStatus to help architecture
> maintainers in writing such code).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
  

On Fri, 4 Feb 2022, H.J. Lu via Libc-alpha wrote:

> On Fri, Feb 4, 2022 at 12:00 PM Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote:
> >
> > > DT_RELR is enabled in glibc shared libraries and position independent
> > > executables (PIE) automatically if linker supports -z pack-relative-relocs
> > > nd the architecture defines SUPPORT_DT_RELR in config.h.  At the moment,
> > > only x86 targets define SUPPORT_DT_RELR.
> >
> > The patch 1 description says "This patch is simpler than Chrome OS's glibc
> > patch and makes ELF_DYNAMIC_DO_RELR available to all ports.".
> >
> > What exactly would other architectures need to add in glibc to provide
> > RELR support, since I don't see any actual architecture-specific code in
> 
> DT_RELR is enabled only if linker supports -z report-relative-reloc option
> which adds GLIBC_ABI_DT_RELR dependency in the linker output to
> prevent random crashes with the older glibc binaries.

What do you mean by "is enabled"?

Building glibc itself to use such relocations can properly depend on 
linker support.

The set of binaries (executables and shared libraries) glibc can load must 
not depend on linker support.

Those are two different questions.
  

On 2022-02-04, Joseph Myers wrote:
>On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote:
>
>> DT_RELR is enabled in glibc shared libraries and position independent
>> executables (PIE) automatically if linker supports -z pack-relative-relocs
>> nd the architecture defines SUPPORT_DT_RELR in config.h.  At the moment,
>> only x86 targets define SUPPORT_DT_RELR.
>
>The patch 1 description says "This patch is simpler than Chrome OS's glibc
>patch and makes ELF_DYNAMIC_DO_RELR available to all ports.".
>
>What exactly would other architectures need to add in glibc to provide
>RELR support, since I don't see any actual architecture-specific code in
>this patch series outside of configure scripts?  Please provide text you
>would propose to add to https://sourceware.org/glibc/wiki/PortStatus that
>gives an architecture maintainer all the information needed to add such
>support for their architecture.  If in fact no architecture-specific code
>should be needed, please remove the SUPPORT_DT_RELR handling and just
>allow glibc to support the feature for all architectures (while using RELR
>in glibc itself for architectures where the linker support is present, as
>detected by a configure test on the linker rather than hardcoding
>information about which architectures have that linker support at a given
>time).
>
>The default should be to support a feature for all architectures.  A patch
>series supporting a feature for only some architectures needs a positive
>reason for excluding other architectures (for example, that each
>architecture needs architecture-specific code, for which you provide
>suitable documentation to add to PortStatus to help architecture
>maintainers in writing such code).

The patch series mix two things.

"elf: Support DT_RELR relative relocation format [BZ #27924]" allows
user programs to use DT_RELR. This is the main benefit.

AIUI the other patches are to allow x86-64 libc.so.6 to be built with
DT_RELR. This is more for dogfooding purposes and helps binutils port
maintainers confirm their ld.bfd support handles some uncommon cases
(glibc shared objects).

The second part needs a https://sourceware.org/glibc/wiki/PortStatus
entry.

---

(Personally I'd prefer separate patches.
But with some frustration on
https://sourceware.org/pipermail/libc-alpha/2021-November/133009.html
I don't care in what form glibc will get DT_RELR support...
and I really appreciate that H.J contributed the ld.bfd support and
drives this glibc effort.
)