| Message ID | 20220203180948.2744-1-hjl.tools@gmail.com |
|---|---|
| Headers | show |
| Series | Support DT_RELR relative relocation format | expand |
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. )
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