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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 60E221F8C6 for ; Mon, 9 Aug 2021 17:59:57 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1F457383940A for ; Mon, 9 Aug 2021 17:59:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F457383940A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628531996; bh=eMFgoRTLyfmzfB4MxZtDuvW/F89OLgG1jpzao8Je9ts=; 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=l+MyZLoir6z8fuHuLWFDyd31PF6FgM1uY8AgIPchFr5otIbkzqBYKQ+s9J2KWIWfu B2fl112Lw2JelDlcBDP1S63AGIjw4W2tzQc2fvCDqVwpf7j2KWyTGXJdOgbfZSLefP YCheoRdyHlxKuVZ5HeIcvZ7rsXynyEz7Vqw0YSfE= Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 69D773858001 for ; Mon, 9 Aug 2021 17:59:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 69D773858001 Received: by mail-pj1-x1030.google.com with SMTP id cp15-20020a17090afb8fb029017891959dcbso102772pjb.2 for ; Mon, 09 Aug 2021 10:59:26 -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=eMFgoRTLyfmzfB4MxZtDuvW/F89OLgG1jpzao8Je9ts=; b=XjENqzSm0kuSU0Mq3XyTaLfDQbVdzbv5qwVnaClI5l6wP6BhVLq31sOHDabWgEvdCs GCZPt5s02i1gzfeOIa5I2gzcLxHiERTK8kpv41t7U4yEWOPrca+NPUJVJyak3Z6G5ojQ JHC7ESeIrbWuxkIzwQQohUFoHvEsAaAMB0zUo48MuwvGzRV9O0jG3GeGTwdqmSsClTDH 4YCPc1Me86EJhWCZSt7PjuixtiJOtozn2VNbBH81q8X/aGLMQxBv1+cmDCadplhkvF2q P5FlXjUfH5SJNSydxwv71I1MyOPUjxGBxBxaaZs17+sTaqBeta6zWiOlu305NRka1QOu nUug== X-Gm-Message-State: AOAM532oRgcm2eCJr8hWd4SG+hC3j5IafOGPFDc1s1WOVPZFIkYVTgPU njOcxR6SPCS0gkT+mhp9DLRDA0EE1zDzJPlahtw= X-Google-Smtp-Source: ABdhPJwjsDnrVydFYaugD6gTZ6pGAHs8LOwOz6HgzkFbHy1q29HyVDBY9lhR3dI4QI6yzR+mPCYb02Q85clLSyXxQLY= X-Received: by 2002:a65:5b86:: with SMTP id i6mr329130pgr.180.1628531965510; Mon, 09 Aug 2021 10:59:25 -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: <20210808041716.udolcra3nx7af7zw@google.com> Date: Mon, 9 Aug 2021 10:58:49 -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 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 prints 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 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) 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=3D13302 > >> >> > > >> >> > Please fix it at least on x86. > >> >> > >> >> I am afraid that I disagree. The PowerPC port of GNU ld does the ri= ght > >> > > >> >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 belon= g > >> >> to .rela.dyn instead of .rela.plt. > >> > > >> >Ulrich and I designed/implemented IFUNC on x86 and for x86. I consid= er > >> >x86 implementation of IFUC as the gold standard. > >> > >> kib from FreeBSD said > >> > >> "FreeBSD rtld does the initial pass over the plt relocations and handl= es > >> R_X86_64_JMP_SLOT only, If there are any R_X86_64_IRELATIVE relocks, w= e > >> 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 diffe= rent. > >> 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 rel= ocations. > >> Fixing this property in glibc will improve rubustness/flexibility of i= func > >> 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 impli= cation. > >> > > > >On Linux/x86, lld is incompatible with ld.so on this particular IFUNC fe= ature. > >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 =3D> R_X86_64_64 referencing STT_GNU_IFUNC in .rela.d= yn > 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. > 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)() =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 IRE= LATIVE is not correct. I don't believe this is the use case we want to support. > > If glibc adopts the FreeBSD model, then all these will be good, along wit= h LLD's .rela.dyn IRELATIVE. > An ifunc resolver can call functions defined in an arbitrary DT_NEEDED. --=20 H.J.