Undelivered Mail Returned to Sender

[MAILER-DAEMON (Mail Delivery System)]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 13755 bytes --]

From: "Fāng-ruì Sòng via Libc-alpha" <libc-alpha@sourceware.org>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2 3/3] configure: Allow LD to be LLD 13.0.0 or above [BZ #26558]
Date: Tue, 10 Aug 2021 10:42:36 -0700
Message-ID: <CAFP8O3KmMzDJGw4VOjePLo+WNtt4HFpj12KHyC9xkSZTggRnJQ@mail.gmail.com>

On Tue, Aug 10, 2021 at 7:38 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Aug 9, 2021 at 12:59 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On Mon, Aug 9, 2021 at 10:59 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > 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.
> >
> > Since you are familiar with dynamic linking, perhaps you can offer the
> > ld.so fix  (postponing ifunc resolver invocation after other regular
> > relocations) :)
>
> Please open a glibc bug so that we can track it.   We should first
> decide if we want to support this use case.

https://sourceware.org/bugzilla/show_bug.cgi?id=28218
("ld.so: ifunc resolver calls a lazy PLT. When does it work?")

> > Once a separate relocation loop for ifunc is created, it is trivial
> > for non-x86 arch maintainers to make ifunc more reliable for their
> > arches.
> >
> > Then users can build more trust on ifunc.
> >
> >
> > Let me consider this sub-thread a non-blocker for LLD 13.0.0 support.
> >
> > > > 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.
> >
> > Do we have easy-to-explain words on what's supported and what's not?
>
> This has been a recurring topic. We should have some guidance
> on IFUNC.  IFUNC was designed for glibc.  It was later extended to
> other use cases.  There are limitations, like
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=20019
>
> We need clear descriptions about how IFUNC should be used.
>
> > > >
> > > > 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.
>
>
>
> --
> H.J.


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=153.6112bf75.cd1b8.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+%5BPATCH+v2+3%2F3%5D+configure%3A+Allow+LD+to+be+LLD+13.0.0+or+above+%5BBZ+%2326558%5D&verdict=C&c=b66724c82cc7908c8c60246cb32098d762ef4505