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_MED,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 3EFC31F8C6 for ; Tue, 10 Aug 2021 18:03:39 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 310D63958C31 for ; Tue, 10 Aug 2021 18:03:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 310D63958C31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628618618; bh=8BhmKTS2aenRvA1F/X4+9tIQMVuBITXHiVLN+LVqBSI=; 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=JEWYb3lAJumy4iflXrDXZClbxwhKpfLyEIZITl7VLUTUZ9dU3Ot5M5Fv8kfgpSNzI IzVMMfyprT1QynYk/FyAFjPwb3O1WLF7Qlfm4uoZUO2ZqMSO4Yr3OdzBJmfN7EEOaJ j2fq25f1XonOk2YK80p/maJfSSaxgHCY0Vk5rnzQ= Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by sourceware.org (Postfix) with ESMTPS id 4F3F7386FC39 for ; Tue, 10 Aug 2021 17:42:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F3F7386FC39 Received: by mail-yb1-xb31.google.com with SMTP id l3so5250209ybt.7 for ; Tue, 10 Aug 2021 10:42:48 -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=8BhmKTS2aenRvA1F/X4+9tIQMVuBITXHiVLN+LVqBSI=; b=SgOiLsk26CKl6ZnOUNbKj7WbNYi1JQjDCDQzFVTEvvN+RTZn2tU0SbPL6MTh9uGOB/ mF6QIHfNeG0Bn4ok2EeFZidmbCl/bgmhy0LlW/GCYb8fCp85FKDZ9XUUEWEWAKeve+ab FP91d+0lnfYOF9SmO2Xc7AfCwk9X6Wl3zncXWnlqziFm3ilR0jOVWVxijb14YqDGnkoA +gl/6cp4vCyFpqM0ZicCl+K11SYtbN4iDlO7v+bQeZL8Ug+q1P2bsDU9DZMC7kDxiJft EK1x4HQ3hizS1XPySAxI1IM58WOzmQp4a3GLtY2133qDWQJ0i3hdxi2n3YTq+ZK4g//K O9Nw== X-Gm-Message-State: AOAM532IPaVytNWg0FA0KHAbN4yB8hcnzcFZpUe6graSdeO63DkUAWFE m9Y6xQwKpEq1qWl/6STAxLYe/cO84Fg0LGqffEdn+A== X-Google-Smtp-Source: ABdhPJy7BQKEZkXbZjr+gith/s50q2gvNcHKf1Db+ExFI5FXSCDNMt8LnAM+Juvm62wtIE4Ze1gl5YL/T+TLuCJb4GE= X-Received: by 2002:a5b:8cd:: with SMTP id w13mr41768163ybq.106.1628617367683; Tue, 10 Aug 2021 10:42:47 -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 10:42:36 -0700 Message-ID: Subject: Re: [PATCH v2 3/3] configure: Allow LD to be LLD 13.0.0 or above [BZ #26558] To: "H.J. Lu" 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: =?utf-8?q?F=C4=81ng-ru=C3=AC_S=C3=B2ng_via_Libc-alpha?= Reply-To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: GNU C Library Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Tue, Aug 10, 2021 at 7:38 AM H.J. Lu wrote: > > 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 = 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 pri= nts a confusing > > > > >> >> > > message. > > > > >> >> > > > > > > >> >> > > *** These critical programs are missing or too old: G= NU ld > > > > >> >> > > > > > > >> >> > > LLD>=3D13.0.0 can build glibc --enable-static-pie. (8.0.0= needs 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) fi= xed, > > > > >> >> > > `make check` only has 2 more failures with LLD than with = GNU ld: > > > > >> >> > > BZ #28154 (LLD follows the PowerPC port of GNU ld for ifu= nc 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 = the right > > > > >> > > > > > >> >This is just one opinion and it doesn't make it "the right thin= g". > > > > >> > > > > > >> >> 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 relo= cks, we > > > > >> mark the object as having such relocations. Then, we do the irel= oc > > > > >> processing, using the depth-first descend. We handle all IRELOCs= for > > > > >> dependent objects before doing it for dependee. There, we iterat= e over > > > > >> all plt relocs to select IRELOCs." > > > > >> > > > > >> I pondered at this comment > > > > >> > > > > >> /* > > > > >> * The handling of R_MACHINE_IRELATIVE relocations and jumpslot= s > > > > >> * referencing STT_GNU_IFUNC symbols is postponed till the othe= r > > > > >> * 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 indirect= s. > > > > >> * > > > > >> * 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 hap= pen in > > > > >> DT_JMPREL after the DT_REL* relocations, but that is no guarante= e 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 ro= bust, even for > > > > >> x86. IRELATIVE is still eager resolved, just postponed after oth= er relocations. > > > > >> Fixing this property in glibc will improve rubustness/flexibilit= y of ifunc > > > > >> resolvers and freeing linkers the responsibility to order IRELAT= IVE in a > > > > >> particular position. > > > > >> > > > > >> Pioneering on one feature gives the designer respect, yet the de= signer 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 IF= UNC 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 i= s > > > > 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 =3D> R_X86_64_64 referencing STT_GNU_IFUNC in .= rela.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. https://sourceware.org/bugzilla/show_bug.cgi?id=3D28218 ("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 i= nstead 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, alo= ng with LLD's .rela.dyn IRELATIVE. > > > > An ifunc resolver can call functions defined in an arbitrary DT_NEE= DED. > > > > > > > > > > > > -- > > > H.J. > > > > -- > H.J.