From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <> Received: from fx302.security-mail.net (mxout.security-mail.net [85.31.212.42]) by sourceware.org (Postfix) with ESMTPS id F34B93857400 for ; Tue, 10 Aug 2021 14:39:07 +0000 (GMT) Authentication-Results: sourceware.org; dkim=permerror (bad message/signature format) Received: by fx302.security-mail.net (Postfix) id 3372B3D3B095; Tue, 10 Aug 2021 16:39:07 +0200 (CEST) Date: Tue, 10 Aug 2021 16:39:07 +0200 (CEST) From: MAILER-DAEMON (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: libc-alpha@sourceware.org Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="ECC0D3D3B0E6.1628606347/fx302.security-mail.net" Content-Transfer-Encoding: 8bit Message-Id: <20210810143907.3372B3D3B095@fx302.security-mail.net> X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 14:39:18 -0000 This is a MIME-encapsulated message. --ECC0D3D3B0E6.1628606347/fx302.security-mail.net Content-Description: Notification Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This is the mail system at host fx302.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 : host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command) --ECC0D3D3B0E6.1628606347/fx302.security-mail.net Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; fx302.security-mail.net X-Postfix-Queue-ID: ECC0D3D3B0E6 X-Postfix-Sender: rfc822; libc-alpha@sourceware.org Arrival-Date: Tue, 10 Aug 2021 16:39:06 +0200 (CEST) Final-Recipient: rfc822; mpoulhies@kalray.eu Original-Recipient: rfc822;mpoulhies@kalray.eu Action: failed Status: 5.1.1 Remote-MTA: dns; zimbra2.kalray.eu Diagnostic-Code: smtp; 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table --ECC0D3D3B0E6.1628606347/fx302.security-mail.net Content-Description: Undelivered Message Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) by fx302.security-mail.net (Postfix) with ESMTPS id 3393B3D3B095 for ; Tue, 10 Aug 2021 16:39:05 +0200 (CEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C20A2386FC08 for ; Tue, 10 Aug 2021 14:39:03 +0000 (GMT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id 978C63858024 for ; Tue, 10 Aug 2021 14:38:39 +0000 (GMT) Received: by mail-pj1-x1031.google.com with SMTP id lw7-20020a17090b1807b029017881cc80b7so4648481pjb.3 for ; Tue, 10 Aug 2021 07:38:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: E-securemail, by Secumail X-Spam-Status: No, score=-2.149 tagged_above=-1000 required=7.5 tests=[AB_ENVFROM_LONG_40=0.5, AB_IN_REPLY_TO_EXISTS=-1, AB_LONG_SUBJ_30=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-1, DKIM_VALID_AU=-0.1, FAKE_REPLY_SURE_A=1, FAKE_REPLY_SURE_B=1, FSL_RCVD_EX_3=0.01, FSL_RCVD_UT_3=0.01, HEAD_NEWS=-0.5, MISSING_MID=0.14, MM_ENVFROM_BOUNCE=1, RCVD_IN_DNSWL_MED=-1.3, S_FROM_GREY_MINUS_2=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Authentication-Results: fx302.security-mail.net (amavisd-new); dkim=pass (1024-bit key) header.d=sourceware.org Secumail-id: <2093.61128f89.59cc.0> DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C20A2386FC08 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628606343; bh=cbtB91pQzcZZAoSNsEWDre3yXUqI0WGbwec326mq5Nk=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=CpULxf/4Ef5BoJNSPQxQXTTbV8acvjTZzZ3eiB3Iq+c97jGUDUWddp77Aw0b6RYgE kwn1k6cn180zAy0+RreFxZBPHRuMuazk4yLEOpTCPXOMEsgC03pr7fPg2sUbIV2q3C V0rRETgWVfWbE8RCw2UxLmLQIW2Ti+FVO4BUSwbE= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 978C63858024 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cbtB91pQzcZZAoSNsEWDre3yXUqI0WGbwec326mq5Nk=; b=jMGUrq5vkluIybk5tliwcm+49mVWLK12hWO3oIv55PfMZ7mU9Zp+5izV+n+pi8T/x2 /nrcNkZPrgfIuNKcqqcuaefz4rI+nIARmYt4LQrwzWV72zvEVoNpOrJPpx4sMrWuzPpf gkU4dZr1PMQQ6z1ODTyFcMxqRTBoGuDpHFi9i5GJX4GOHZnjTGZLS85HA5nWFk8IzYr5 VZrwWBHCNe1Eln/pdoMb2GHqiiqAeM+xSbB8xI3xhwHit9dLYp7+fDYFZhAigNl1XQ2U IxqTpw8oYm/Ic4H1axxHnfPmOzJarpDu0s8Zjn6ntIGB+WAxD04hbprcKdHk8m21SxWP GZ2g== X-Gm-Message-State: AOAM5338+NqcIqf59tdyTggOi+BhhmolRGSyRQpqKu+DQ7acJtEvJpww iNN1dmLgv272Nreaa47HZSYXGojce1XTkBNZquA= X-Google-Smtp-Source: ABdhPJyjPbJ6xpm9E/fLAm580/kPT5D2gdzuaW6hCj7Ya4lLULC/sCtkDeafmT7+hkLrMT20NJPGiMlEjEFUPMOaCNw= X-Received: by 2002:a17:90a:4404:: with SMTP id s4mr5279029pjg.153.1628606318718; Tue, 10 Aug 2021 07:38:38 -0700 (PDT) MIME-Version: 1.0 References: <20210805162601.1200851-1-maskray@google.com> <20210805162601.1200851-4-maskray@google.com> <20210807004759.7rskhwijvxaoaoja@google.com> <20210808041716.udolcra3nx7af7zw@google.com> In-Reply-To: Date: Tue, 10 Aug 2021 07:38:02 -0700 Message-ID: Subject: Re: [PATCH v2 3/3] configure: Allow LD to be LLD 13.0.0 or above [BZ #26558] To: =?utf-8?b?RsSBbmctcnXDrCBTw7JuZw==?= X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: GNU C Library Errors-To: libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org Sender: Libc-alpha X-ALTERMIMEV2_in: done Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On Mon, Aug 9, 2021 at 12:59 PM Fāng-ruì Sòng wrote: > > On Mon, Aug 9, 2021 at 10:59 AM H.J. Lu wrote: > > > > On Sat, Aug 7, 2021 at 9:17 PM Fāng-ruì Sòng wrote: > > > > > > > > > > > > On 2021-08-07, H.J. Lu wrote: > > > >On Fri, Aug 6, 2021 at 5:48 PM Fāng-ruì Sòng wrote: > > > >> > > > >> On 2021-08-05, H.J. Lu wrote: > > > >> >On Thu, Aug 5, 2021 at 9:43 AM Fāng-ruì Sòng wrote: > > > >> >> > > > >> >> On Thu, Aug 5, 2021 at 9:34 AM H.J. Lu wrote: > > > >> >> > > > > >> >> > On Thu, Aug 5, 2021 at 9:29 AM Fangrui Song via Libc-alpha > > > >> >> > 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 > > > > > > 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. > 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 > > > > > > 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=2093.61128f89.59cc.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=0f09648365b0c17616257533dfe06e9233f5babe --ECC0D3D3B0E6.1628606347/fx302.security-mail.net--