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

[Fāng-ruì Sòng]

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.

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.


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.