[PATCH] elf: Support DT_RELR relative relocation format [BZ #27924]

[H.J. Lu]

On Fri, Oct 8, 2021 at 10:37 AM Fangrui Song <maskray@google.com> wrote:
>
> On 2021-10-08, H.J. Lu wrote:
> >On Thu, Oct 7, 2021 at 11:58 PM Fangrui Song via Binutils
> ><binutils@sourceware.org> wrote:
> >>
> >> PIC objects (especially PIE and symbolic 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 welcomed by many parties
> >> (including Solaris). This packed format can typically save 95% dynamic
> >> relocation section size for PIE. The vaddr size of a PIE can be 10% smaller.
> >>
> >> * Chrome OS folks have carried a local patch for a while (latest version:
> >>   https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-libs/glibc/files/local/glibc-2.32).
> >>   I.e. this feature has been battle tested.
> >> * Android bionic supports DT_RELR.
> >> * The Linux kernel has supported CONFIG_RELR since 2019-08
> >>   (https://git.kernel.org/linus/5cf896fb6be3effd9aea455b22213e27be8bdb1d).
> >> * A musl patch (by me) exists but is not applied:
> >>   https://www.openwall.com/lists/musl/2019/03/06/3
> >>
> >> I believe upstream glibc should support DT_RELR to benefit all Linux
> >> distributions.
> >>
> >> As of linker support (to the best of my knowledge):
> >>
> >> * LLD support DT_RELR.
> >> * https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-devel/binutils/files/
> >>   has a gold patch.
> >> * GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=27923
> >>
> >> I wish that GNU ld and gold maintainers can implement the feature as well :)
> >
> >This feature should be implemented in GNU linker first before getting
> >into glibc.
> >
> >
> >H.J.
>
> Why? I think the situation is quite different from other features where
> we generally want producers before consumers.  The feature is validated
> by multiple parties and has multiple independent implementations and has
> an implementation in a glibc supported linker (LLD).

This feature should be validated by the default glibc linker.   Otherwise,
things can go wrong unnoticed.

> Landing into glibc first can do GNU linker folks a favor: they don't
> need to apply the glibc patch themselves to validate correctness of the
> linker change.

This has never been a real issue.  We prefer to test linker correctness
independent of host, library and/or CPU.

-- 
H.J.