From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 02C21381DCCB for ; Wed, 6 Jan 2021 02:14:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 02C21381DCCB Received: by mail-oi1-x22b.google.com with SMTP id p5so1889881oif.7 for ; Tue, 05 Jan 2021 18:14:47 -0800 (PST) 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=gku26lPIQIkUKBgUulq7JoWDQ7H6T0t6w/tANAfSNYg=; b=HapnRU+DRLbm/Gr6NtS73OCUwTQmUfVSKb3DKl0h8QitkbDEFONc1ZhoQioTzddO27 aB+1iKrsiidGRA+EKLutUFbGbwX4LRNPVu82eieQdYFg/42g9rPDuLtAeav+QD7BWTM/ euw5Cx1BeG4ZjCSTspiZAOeeFNSftasEjil/5nEy0Y+h11hw3PRiaxOSm6+q/TvuHxjT dx2zHSToxjWH8RLDTBLVvdGJkLn/i6F4F0SsMoGqwBJgUEwu5GUsg6FM5xaP2U5KploL 9GmE5kBjr/t2jz1i2p2684qalAvLzQY5nzItr+wTvAaYP0aq1EnQ4CvxrUmXELSuDHH7 XGGw== X-Gm-Message-State: AOAM5339rlq0RY4rAtbfdWXQtRckXNJTWJB06txIvD1binEDE+jBCpDp ODfkzKy65oLoG/atF3tCZE0MIJOIYWZbmzDRpK8= X-Google-Smtp-Source: ABdhPJzHIcfKQB7mEfepkC0/3YPtI5UNqWVGkWXjHynpX594BQhEHIc306bcNHHLtUREPBnTaWkTElsMPa2Swe64O5w= X-Received: by 2002:aca:f456:: with SMTP id s83mr1780493oih.58.1609899286249; Tue, 05 Jan 2021 18:14:46 -0800 (PST) MIME-Version: 1.0 References: <20201228194855.510315-1-maskray@google.com> <20201228214541.phbfjgv2ft3mgikj@google.com> In-Reply-To: From: "H.J. Lu" Date: Tue, 5 Jan 2021 18:14:09 -0800 Message-ID: Subject: Re: [PATCH 0/3] Make glibc build with LLD To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3030.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Wed, 06 Jan 2021 02:14:50 -0000 On Tue, Jan 5, 2021 at 6:00 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > On Tue, Jan 5, 2021 at 5:44 PM H.J. Lu wrote: > > > > On Tue, Jan 5, 2021 at 4:51 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > > > > On Tue, Jan 5, 2021 at 3:52 PM H.J. Lu wrote: > > > > > > > > On Tue, Jan 5, 2021 at 3:41 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > > > > > > > > On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu wrot= e: > > > > > > > > > > > > On Tue, Jan 5, 2021 at 3:03 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > > > > > > > > > > > > On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu = wrote: > > > > > > > > > > > > > > > > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu wrote: > > > > > > > > > > > > > > > > > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song wrote: > > > > > > > > > > > > > > > > > > > > On 2020-12-28, H.J. Lu wrote: > > > > > > > > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc= -alpha > > > > > > > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > >> I sent the first two in April. Resending in a patch = series to be > > > > > > > > > > >> clearer. > > > > > > > > > > >> > > > > > > > > > > >> install: Replace scripts/output-format.sed with ob= jdump -f > > > > > > > > > > >> > > > > > > > > > > >> replaced https://sourceware.org/pipermail/libc-alpha= /2020-April/112733.html > > > > > > > > > > >> by leveraging objdump -f. > > > > > > > > > > >> > > > > > > > > > > >> With this patch series (available in https://sourcew= are.org/git/?p=3Dglibc.git;a=3Dshortlog;h=3Drefs/heads/maskray/lld), > > > > > > > > > > >> `make` with ld pointing to ld.lld (LLVM linker) work= s. > > > > > > > > > > > > > > > > > > > > > >I tried your branch with "LLD 11.0.0 (compatible with = GNU linkers)" on > > > > > > > > > > >Fedora 33/x86-64, > > > > > > > > > > >"make check" generated: > > > > > > > > > > > > > > > > > > > > > >make[4]: *** [../Makerules:767: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-tlsmod2.so] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Makerules:767: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-tlsmod4.so] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Makerules:767: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-absolute-sym-lib.so] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Makerules:767: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-absolute-zero-lib.so] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Makerules:767: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-tlsmod6.so] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Makerules:767: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-tlsmod5.so] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Rules:226: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-audit16] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Rules:226: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-audit14] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Rules:226: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-audit15] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Rules:226: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/tst-tls1] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Rules:226: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/ifuncmain5] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[4]: *** [../Rules:226: > > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-l= ld/build-x86_64-linux/elf/ifuncmain1] > > > > > > > > > > >Error 1 > > > > > > > > > > >make[3]: *** [Makefile:479: elf/tests] Error 2 > > > > > > > > > > > > > > > > > > > > > >with error messages, like > > > > > > > > > > > > > > > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/gli= bc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os > > > > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS sect= ion > > > > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/gli= bc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os > > > > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS sect= ion > > > > > > > > > > > > > > > > > > > > tst-tls* tests appear to be similar to .tls_common whic= h looks very > > > > > > > > > > obsoleted and not supported by Clang. I don't think ifu= ncmain* or > > > > > > > > > > tst-audit* matters for typical usage (most users) but I= can take a look. > > > > > > > > > > > > > > > > > > "make check" should be clean on Fedora 33/x86-64. > > > > > > > > > > > > > > > > Because this lld error, "make check" didn't report test sum= mary: > > > > > > > > > > > > > > > > Summary of test results: > > > > > > > > 4322 PASS > > > > > > > > 8 UNSUPPORTED > > > > > > > > 13 XFAIL > > > > > > > > 6 XPASS > > > > > > > > > > > > > > > > > > >When glibc is configured with --enable-static-pie, I g= ot > > > > > > > > > > > > > > > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig > > > > > > > > > > >Segmentation fault (core dumped) > > > > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ > > > > > > > > > > > > > > > > > > > > > >You need to fix lld first and give the working lld a p= roper version so that > > > > > > > > > > >configure can check it. > > > > > > > > > > > > > > > > > > > > I cherry picked "Make _dl_relocate_static_pie return an= int indicating whether it applied relocs." > > > > > > > > > > in google/grte/v5-2.27/master, which has fixed the issu= e. > > > > > > > > > > > > > > > > > > Why isn't it needed for ld? > > > > > > > > > > > > > > > > > > > > > > > > > Also re-order your patches to place the enabling lld patch = the last so that any > > > > > > > > commits can build a working glibc. > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > -- > > > > > > > > H.J. > > > > > > > > > > > > > > Without "configure: Allow LD to be LLD 9.0.0 or above", confi= gure > > > > > > > rejects LLD at configure time and the other commits cannot be= tested > > > > > > > at all... > > > > > > > > > > > > > > The other commits are general improvement and useful on their= own, and > > > > > > > they are independent and can be merged separately. > > > > > > > > > > > > > > As I mentioned in the other reply, LLD does not want to speci= al case > > > > > > > the definition of __rela_iplt_start depending on -no-pie (ava= ilable in > > > > > > > gold and LLD, not available in GNU ld yet) ; -pie/-shared... > > > > > > > The TLS common issues are obsoleted features that do not make= sense nowadays. > > > > > > > Any case, the LLD produced executables are functional. > > > > > > > > > > > > The code in question is > > > > > > > > > > > > static void > > > > > > apply_irel (void) > > > > > > { > > > > > > # ifdef IREL > > > > > > /* We use weak references for these so that we'll still work = with a linker > > > > > > that doesn't define them. Such a linker doesn't support I= FUNC at all > > > > > > and so uses won't work, but a statically-linked program th= at doesn't > > > > > > use any IFUNC symbols won't have a problem. */ > > > > > > extern const IREL_T IPLT_START[] __attribute__ ((weak)); > > > > > > extern const IREL_T IPLT_END[] __attribute__ ((weak)); > > > > > > for (const IREL_T *ipltent =3D IPLT_START; ipltent < IPLT_END= ; ++ipltent) > > > > > > IREL (ipltent); > > > > > > # endif > > > > > > } > > > > > > > > > > > > Since IPLT_START and IPLT_END are undefined, linker should set > > > > > > them to zero and the loop should be skipped. Why doesn't LLD d= o > > > > > > that? > > > > > > > > > > > > > > > > > > -- > > > > > > H.J. > > > > > > > > > > LLD defines __rela_iplt_start/__rela_iplt_end if (1) __rela_iplt_= start > > > > > exists and is not defined (2) not -r (3) no .interp > > > > > > > > > > LLD defines __rela_iplt_start regardless of -no-pie/-pie. This > > > > > behavior makes sense to me. > > > > > GNU ld and gold seem to only define __rela_iplt_start in -no-pie = mode. > > > > > > > > It is an lld bug: > > > > > > > > https://bugs.llvm.org/show_bug.cgi?id=3D48674 > > > > > > > > -- > > > > H.J. > > > > > > I don't consider https://bugs.llvm.org/show_bug.cgi?id=3D48674 an LLD > > > bug, so we have disagreement. > > > > > > __rela_iplt_start/__rela_iplt_end is a contract between the link > > > editor and the dynamic loader/libc. For the perspective of a good > > > design, I don't think it is necessary making > > > "whether to define __rela_iplt_start" different for ld -no-pie (GNU l= d > > > does not have -no-pie currently, but gold and LLD do) and ld -pie. > > > > > > rtld/libc can just figure out whether it is -static-pie (since a > > > different crt1 rcrt1.o is used) and don't reference __rela_iplt_start > > > in that case. > > > > > > If this difference is dropped (by taking the glibc patch "Make > > > _dl_relocate_static_pie return an int indicating whether it applied > > > relocs."), > > > diff -u =3D(ld.bfd --verbose) =3D(ld.bfd -pie --verbose) can have no > > > difference other than the start address: __executable_start. > > > > I designed and implemented the whole thing in ld and glibc > > many years ago. > > I see, binutils commit 3aa14d16c669ca75f9fa4e995a2e2d13069dff3f > (2009-06-01) added __rela_iplt_start. > > > I don't think they should be changed. lld should follow my design. > > However, that was before glibc gained static pie support (2017; > http://sourceware.org/PR19574). With static pie, I think > __rela_iplt_start should be revised. > I have made many compatibility changes to LLD, but this one seems > unreasonable, so I am not inclined to folllow. > I'll personally add this to my list of incompatibilities > https://maskray.me/blog/2020-12-19-lld-and-gnu-linker-incompatibilities Please move the IFUNC discussion to https://bugs.llvm.org/show_bug.cgi?id=3D48674 --=20 H.J.