From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id E8085386184C for ; Tue, 5 Jan 2021 23:03:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E8085386184C Received: by mail-pj1-x1036.google.com with SMTP id n3so1681555pjm.1 for ; Tue, 05 Jan 2021 15:03:17 -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; bh=BrfkdYCB3dqT079sCycjCjAvIzeMLvD7Z4vFAAcI/q0=; b=bK7WB6nW/MUjnuF8aeKml+eKeHp5XLiC5TWnxT/TMZ11Ra6F9kDROILOHKlUjxDrr/ 4aQA/jWYOMILzhkirRiL9O/RMOrRbOUmJ2+PH8v6vNLIubWr+oU2AYeVDZNl4FT0GzLo YZnGmZ4DWOOC5NuW9qeP5YoiPUC4gYyVpcbbeoY1skuAtjWHumH4LZ6mjuErpzoKRNuq e1Wm5fv+M9aTWmgve6Z75JSMVfKXz6mNglQj0pzVlHfrADAFqZF6zw5pZt/zNODuSgRh OnmMkukVMhmxRghGGMWii/dzhccjU28QzlkQuzWB+eHUGeaJtAxLlJx1zZRtMz7/XqYJ jD2w== X-Gm-Message-State: AOAM530pYNxQP8vMiBRR4kmcN0C3yV5GjM8v076367f8B17pRo/1QJh0 GNTjj7pxK+db4cEbl9Xz+aGlwx/oA49nvZQA6Jv4Lyj2UPizqA== X-Google-Smtp-Source: ABdhPJyxim9h7ScInkZ17T5Tvt32rUfd5iEWGEKgYQhOJpOWEUmv0Ooji8FKc+OZx1lRGQdxnxyo6dVSIvpHyHv++vk= X-Received: by 2002:a17:902:7793:b029:da:d44d:1968 with SMTP id o19-20020a1709027793b02900dad44d1968mr1598999pll.47.1609887796943; Tue, 05 Jan 2021 15:03:16 -0800 (PST) MIME-Version: 1.0 References: <20201228194855.510315-1-maskray@google.com> <20201228214541.phbfjgv2ft3mgikj@google.com> In-Reply-To: From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Tue, 5 Jan 2021 15:03:05 -0800 Message-ID: Subject: Re: [PATCH 0/3] Make glibc build with LLD To: "H.J. Lu" Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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: Tue, 05 Jan 2021 23:03:19 -0000 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 objdump -f > > > >> > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html > > > >> by leveraging objdump -f. > > > >> > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld), > > > >> `make` with ld pointing to ld.lld (LLVM linker) works. > > > > > > > >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-lld/build-x86_64-linux/elf/tst-tlsmod2.so] > > > >Error 1 > > > >make[4]: *** [../Makerules:767: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so] > > > >Error 1 > > > >make[4]: *** [../Makerules:767: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/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-lld/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-lld/build-x86_64-linux/elf/tst-tlsmod6.so] > > > >Error 1 > > > >make[4]: *** [../Makerules:767: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so] > > > >Error 1 > > > >make[4]: *** [../Rules:226: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16] > > > >Error 1 > > > >make[4]: *** [../Rules:226: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14] > > > >Error 1 > > > >make[4]: *** [../Rules:226: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15] > > > >Error 1 > > > >make[4]: *** [../Rules:226: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1] > > > >Error 1 > > > >make[4]: *** [../Rules:226: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5] > > > >Error 1 > > > >make[4]: *** [../Rules:226: > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/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/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section > > > > > > tst-tls* tests appear to be similar to .tls_common which looks very > > > obsoleted and not supported by Clang. I don't think ifuncmain* 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 summary: > > Summary of test results: > 4322 PASS > 8 UNSUPPORTED > 13 XFAIL > 6 XPASS > > > > >When glibc is configured with --enable-static-pie, I got > > > > > > > >[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 proper 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 issue. > > > > 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", configure 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 special case the definition of __rela_iplt_start depending on -no-pie (available 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.