From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 796A91F8C6 for ; Tue, 10 Aug 2021 14:39:10 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 18E62386FC2C for ; Tue, 10 Aug 2021 14:39:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 18E62386FC2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628606349; 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=xgGPsCGOqonDrLVFFKhr/fO6LIeZA6fdJvsDsVZr29y4TyRkiOyPPt3gqVkw/zo9v kL3sBK/EMo/P6wbulP7fXE4Y5VFl7sGjJ8zkqRkaGDH2U9SF9id/V10Z1CW64MaVvg +kLlbOtS0FWGzYDdlA9SFQ6yvKIDffP2wkiHEpFQ= 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) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 978C63858024 Received: by mail-pj1-x1031.google.com with SMTP id lw7-20020a17090b1807b029017881cc80b7so4648481pjb.3 for ; Tue, 10 Aug 2021 07:38:39 -0700 (PDT) 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==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Mon, Aug 9, 2021 at 12:59 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > On Mon, Aug 9, 2021 at 10:59 AM H.J. Lu wrote: > > > > On Sat, Aug 7, 2021 at 9:17 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > > > > > > > > > > On 2021-08-07, H.J. Lu wrote: > > > >On Fri, Aug 6, 2021 at 5:48 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > >> > > > >> On 2021-08-05, H.J. Lu wrote: > > > >> >On Thu, Aug 5, 2021 at 9:43 AM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > >> >> > > > >> >> On Thu, Aug 5, 2021 at 9:34 AM H.J. Lu wr= ote: > > > >> >> > > > > >> >> > On Thu, Aug 5, 2021 at 9:29 AM Fangrui Song via Libc-alpha > > > >> >> > wrote: > > > >> >> > > > > > >> >> > > When using LLD (LLVM linker) as the linker, configure print= s a confusing > > > >> >> > > message. > > > >> >> > > > > > >> >> > > *** These critical programs are missing or too old: GNU= ld > > > >> >> > > > > > >> >> > > LLD>=3D13.0.0 can build glibc --enable-static-pie. (8.0.0 n= eeds one > > > >> >> > > workaround for -Wl,-defsym=3D_begin=3D0. 9.0.0 works with > > > >> >> > > --disable-static-pie). > > > >> >> > > > > > >> >> > > With BZ #28153 (glibc bug exposed by testing with LLD) fixe= d, > > > >> >> > > `make check` only has 2 more failures with LLD than with GN= U 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=3D13302 > > > >> >> > > > > >> >> > Please fix it at least on x86. > > > >> >> > > > >> >> I am afraid that I disagree. The PowerPC port of GNU ld does th= e 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 b= elong > > > >> >> to .rela.dyn instead of .rela.plt. > > > >> > > > > >> >Ulrich and I designed/implemented IFUNC on x86 and for x86. I co= nsider > > > >> >x86 implementation of IFUC as the gold standard. > > > >> > > > >> kib from FreeBSD said > > > >> > > > >> "FreeBSD rtld does the initial pass over the plt relocations and h= andles > > > >> R_X86_64_JMP_SLOT only, If there are any R_X86_64_IRELATIVE relock= s, we > > > >> mark the object as having such relocations. Then, we do the ireloc > > > >> processing, using the depth-first descend. We handle all IRELOCs f= or > > > >> 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 happe= n 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 d= ifferent. > > > >> Such fundamental limitations may be lifted at a future point." > > > >> > > > >> I think adopting the FreeBSD approach can make IRELATIVE more robu= st, 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 IRELATIV= E in a > > > >> particular position. > > > >> > > > >> Pioneering on one feature gives the designer respect, yet the desi= gner can only > > > >> earn authority by demonstrating the consideration of all sort of i= mplication. > > > >> > > > > > > > >On Linux/x86, lld is incompatible with ld.so on this particular IFUN= C feature. > > > >We have 3 choices: > > > > > > > >1. Ignore it. But it means that if lld is used to build glibc, we d= on'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/x8= 6. > > > > > > 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 =3D> R_X86_64_64 referencing STT_GNU_IFUNC in .re= la.dyn > > > int (*fptr_a)() =3D 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=3Dbfd -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 ins= tead 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)() =3D 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=3D20019 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_NEEDE= D. > > > > > > > > -- > > H.J. --=20 H.J.