Re: [PATCH v2 3/3] configure: Allow LD to be LLD 13.0.0 or above [BZ #26558]

["H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>]

On Sat, Aug 7, 2021 at 9:17 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
>
>
> On 2021-08-07, H.J. Lu wrote:
> >On Fri, Aug 6, 2021 at 5:48 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >>
> >> On 2021-08-05, H.J. Lu wrote:
> >> >On Thu, Aug 5, 2021 at 9:43 AM Fāng-ruì Sòng <maskray@google.com> wrote:
> >> >>
> >> >> On Thu, Aug 5, 2021 at 9:34 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >> >> >
> >> >> > On Thu, Aug 5, 2021 at 9:29 AM Fangrui Song via Libc-alpha
> >> >> > <libc-alpha@sourceware.org> wrote:
> >> >> > >
> >> >> > > When using LLD (LLVM linker) as the linker, configure prints a confusing
> >> >> > > message.
> >> >> > >
> >> >> > >     *** These critical programs are missing or too old: GNU ld
> >> >> > >
> >> >> > > LLD>=13.0.0 can build glibc --enable-static-pie. (8.0.0 needs one
> >> >> > > workaround for -Wl,-defsym=_begin=0. 9.0.0 works with
> >> >> > > --disable-static-pie).
> >> >> > >
> >> >> > > With BZ #28153 (glibc bug exposed by testing with LLD) fixed,
> >> >> > > `make check` only has 2 more failures with LLD than with GNU ld:
> >> >> > > BZ #28154 (LLD follows the PowerPC port of GNU ld for ifunc by
> >> >> > > placing IRELATIVE relocations in .rela.dyn).
> >> >> >
> >> >> > This is an lld bug, similar to:
> >> >> >
> >> >> > https://sourceware.org/bugzilla/show_bug.cgi?id=13302
> >> >> >
> >> >> > Please fix it at least on x86.
> >> >>
> >> >> I am afraid that I disagree. The PowerPC port of GNU ld does the right
> >> >
> >> >This is just one opinion and it doesn't make it "the right thing".
> >> >
> >> >> thing and LLD follows suit.
> >> >> R_*_IRELATIVE relocations should be eagerly resolved, so they belong
> >> >> to .rela.dyn instead of .rela.plt.
> >> >
> >> >Ulrich and I designed/implemented IFUNC on x86 and for x86.  I consider
> >> >x86 implementation of IFUC as the gold standard.
> >>
> >> kib from FreeBSD said
> >>
> >> "FreeBSD rtld does the initial pass over the plt relocations and handles
> >> R_X86_64_JMP_SLOT only, If there are any R_X86_64_IRELATIVE relocks, we
> >> mark the object as having such relocations. Then, we do the ireloc
> >> processing, using the depth-first descend. We handle all IRELOCs for
> >> dependent objects before doing it for dependee. There, we iterate over
> >> all plt relocs to select IRELOCs."
> >>
> >> I pondered at this comment
> >>
> >> /*
> >>   * The handling of R_MACHINE_IRELATIVE relocations and jumpslots
> >>   * referencing STT_GNU_IFUNC symbols is postponed till the other
> >>   * relocations are done.  The indirect functions specified as
> >>   * ifunc are allowed to call other symbols, so we need to have
> >>   * objects relocated before asking for resolution from indirects.
> >>   *
> >>   * The R_MACHINE_IRELATIVE slots are resolved in greedy fashion,
> >>   * instead of the usual lazy handling of PLT slots.  It is
> >>   * consistent with how GNU does it.
> >>   */
> >>
> >> and re-read https://sourceware.org/glibc/wiki/GNU_IFUNC
> >>
> >> "This may work on x86_64 where the R_*_IRELATIVE relocations happen in
> >> DT_JMPREL after the DT_REL* relocations, but that is no guarantee that it will
> >> work on AArch64, PPC64, or other architectures that are slightly different.
> >> Such fundamental limitations may be lifted at a future point."
> >>
> >> I think adopting the FreeBSD approach can make IRELATIVE more robust, even for
> >> x86. IRELATIVE is still eager resolved, just postponed after other relocations.
> >> Fixing this property in glibc will improve rubustness/flexibility of ifunc
> >> resolvers and freeing linkers the responsibility to order IRELATIVE in a
> >> particular position.
> >>
> >> Pioneering on one feature gives the designer respect, yet the designer can only
> >> earn authority by demonstrating the consideration of all sort of implication.
> >>
> >
> >On Linux/x86, lld is incompatible with ld.so on this particular IFUNC feature.
> >We have 3 choices:
> >
> >1. Ignore it.  But it means that if lld is used to build glibc, we don't know if
> >this feature works or not.
>
> Let's ignore it :)
>
> It's just 2 tests, representing a corner case of IRELATIVE, which is
> unreliable on non-x86 (as documented) and x86 (see below) anyway.
>
> >2. Change glibc to make it compatible with lld.
> >3. Change lld to make it compatible with glibc.
> >
> >The FreeBSD scheme is not wrong.  But it is a workaround in glibc
> >for a linker bug unless it also fixes other IFUNC issues on Linux/x86.
>
> Let me try convincing you that glibc should be fixed:)
>
>    // a.c
>    #include <stdio.h>
>
>    int a_impl() { return 42; }
>    void *a_resolver() {
>      puts("a_resolver");
>      return (void *)a_impl;
>    }
>    int a() __attribute__((ifunc("a_resolver")));
>
>    // .rela.dyn.rel => R_X86_64_64 referencing STT_GNU_IFUNC in .rela.dyn
>    int (*fptr_a)() = a;
>
>    int main() { printf("%d\n", a()); }
>
> OK, let's compile with gcc and link with GNU ld:
>
> % cc -fpie -c a.c; cc -fuse-ld=bfd -pie a.o -o a; ./a
> [1]    170657 segmentation fault  ./a
>
> Oops. The segfault is very similar to the 2 ld.lld FAIL.

There are restrictions on how IFUNC can be used.   If we want to
support this use case, we need to change ld.so or/and linker.

> Now, you may say, we can change GNU ld to emit R_X86_64_IRELATIVE instead of R_X86_64_64.
>
> Then let's try this:
>
>    // b.c
>    #include <stdio.h>
>
>    int b_impl() { return 42; }
>    void *b_resolver() {
>      puts("b resolver");
>      return (void *)b_impl;
>    }
>    int b() __attribute__((ifunc("b_resolver")));
>
>    int (*fptr_b)() = b;
>
> cc b.c -fpic -shared -o b.so
> Make it a DT_NEEDED of a and see the crash again. b is preemptible so IRELATIVE is not correct.

I don't believe this is the use case we want to support.

>
> If glibc adopts the FreeBSD model, then all these will be good, along with LLD's .rela.dyn IRELATIVE.
> An ifunc resolver can call functions defined in an arbitrary DT_NEEDED.



-- 
H.J.