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 1E4251F8C6 for ; Sat, 7 Aug 2021 13:16:22 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 735203853C3C for ; Sat, 7 Aug 2021 13:16:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 735203853C3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628342180; bh=W2pdByiGsKKmpMG67cmDugNOJKG70J9/8ZMWsIgsVWc=; 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=efw6K/sSANuCmH6/RnFP2wo3SLKwpLu7rvRm/MGURX5h31hlutGjXtVANglKyX1N2 2Vxg/h85pShg63GPoEz9nm4sSxktVhvaA98GfPFI7N6K8NnG3bvPQWx4njNAM4KPYf xWJkKbcM/n5scW9VL2PpwowQxnNcRTgqjdv52L+M= 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 7ECAC3858404 for ; Sat, 7 Aug 2021 13:15:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7ECAC3858404 Received: by mail-pj1-x1030.google.com with SMTP id t7-20020a17090a5d87b029017807007f23so23662304pji.5 for ; Sat, 07 Aug 2021 06:15:58 -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=W2pdByiGsKKmpMG67cmDugNOJKG70J9/8ZMWsIgsVWc=; b=gSqF3endhWHwvn41MbLPcKvU88hxvY3v9FKFPf0yus+Jdq0Fqb18edlBO4wFGpT+dD nqyCFohxTmKd9BwBLjFRi27RbIr23zwhs++4cZh3+Tr7qeq3zKNuVLuRYfhWV6T5uXw3 xFNVTPr6a4/xKJ2yYd4SSMKMmk01PEPtbN6aHbUmG49gVL5LRoDD6e2fdUfEtotMzeqQ azgi8PSpNUu5CkBVlhsiip91XI76pqcW0smW0e1OjyQ8/aXeMkkXFCeFFyZqI9zyM971 Yub4EjvevmrgvjWVpiS7kI27aYUd2R0S3rVtiqez0wdB2McQwo9zC63AtM4998k81SCP N59Q== X-Gm-Message-State: AOAM533/++k3q6Qa7ij2qulwed5mWYy+pzwOmJ3s0FwQ84KY2jzMM/j1 UanVYuJBySiwtJIQL26vsTZ+YCrwgMpAyidtaYw= X-Google-Smtp-Source: ABdhPJy/GIjOqaeUGEPFcRSBDyIDv3WGJVwvCdU6BOlI1pmhssgh01Bh4VRTvMqQJIQybzEbuaGjyiQz6wwAwPAOzJI= X-Received: by 2002:a17:90b:147:: with SMTP id em7mr15645265pjb.154.1628342157643; Sat, 07 Aug 2021 06:15:57 -0700 (PDT) MIME-Version: 1.0 References: <20210805162601.1200851-1-maskray@google.com> <20210805162601.1200851-4-maskray@google.com> <20210807004759.7rskhwijvxaoaoja@google.com> In-Reply-To: <20210807004759.7rskhwijvxaoaoja@google.com> Date: Sat, 7 Aug 2021 06:15:21 -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 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 con= fusing > >> > > 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 on= e > >> > > 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 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 differen= t. > Such fundamental limitations may be lifted at a future point." > > I think adopting the FreeBSD approach can make IRELATIVE more robust, eve= n for > x86. IRELATIVE is still eager resolved, just postponed after other reloca= tions. > Fixing this property in glibc will improve rubustness/flexibility of ifun= c > resolvers and freeing linkers the responsibility to order IRELATIVE in a > particular position. > > Pioneering on one feature gives the designer respect, yet the designer ca= n only > earn authority by demonstrating the consideration of all sort of implicat= ion. > On Linux/x86, lld is incompatible with ld.so on this particular IFUNC featu= re. We have 3 choices: 1. Ignore it. But it means that if lld is used to build glibc, we don't kn= ow if this feature works or not. 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. --=20 H.J.