From: "Fāng-ruì Sòng" <maskray@google.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH 0/3] Make glibc build with LLD
Date: Tue, 5 Jan 2021 15:03:05 -0800 [thread overview]
Message-ID: <CAFP8O3K3Bgzz=x61FGTqShCftGic2wi_x=Q6zoGioX4f4+BrBw@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOrw_Ay=oh2UrwxERvtN2styZZecZ509X2pMKFsHJG5NgA@mail.gmail.com>
On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > >
> > > On 2020-12-28, H.J. Lu wrote:
> > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > ><libc-alpha@sourceware.org> 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.
next prev parent reply other threads:[~2021-01-05 23:03 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-28 19:48 Fangrui Song
2020-12-28 19:48 ` [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold Fangrui Song
2020-12-28 20:46 ` H.J. Lu
2020-12-28 21:15 ` [PATCH 1/3] configure: Allow LD to be LLD 9.0.0 or above " Fangrui Song
2020-12-28 19:48 ` [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld Fangrui Song
2021-01-11 20:06 ` Fāng-ruì Sòng
2021-01-18 22:08 ` Fāng-ruì Sòng
2021-01-19 0:03 ` H.J. Lu
2021-01-19 8:50 ` Fāng-ruì Sòng
2021-01-19 12:30 ` H.J. Lu
2021-01-20 18:51 ` Fāng-ruì Sòng
2021-01-28 1:03 ` Fāng-ruì Sòng
2021-01-29 14:38 ` Adhemerval Zanella
2021-01-29 15:29 ` H.J. Lu
2021-01-29 18:04 ` Adhemerval Zanella
2021-01-29 19:28 ` [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD Fangrui Song
2021-02-01 13:19 ` Adhemerval Zanella
2021-02-01 13:45 ` H.J. Lu
2021-02-01 13:43 ` Florian Weimer
2020-12-28 19:48 ` [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559] Fangrui Song
2021-01-08 19:38 ` Adhemerval Zanella
2021-01-12 11:20 ` Florian Weimer
2021-01-12 12:00 ` Adhemerval Zanella
2021-01-12 17:46 ` Fāng-ruì Sòng
2021-01-12 11:32 ` Andreas Schwab
2021-01-12 11:58 ` Florian Weimer
2020-12-28 21:11 ` [PATCH 0/3] Make glibc build with LLD H.J. Lu
2020-12-28 21:45 ` Fangrui Song
2020-12-28 21:49 ` H.J. Lu
2020-12-28 22:54 ` H.J. Lu
2021-01-05 23:03 ` Fāng-ruì Sòng [this message]
2021-01-05 23:33 ` H.J. Lu
2021-01-05 23:41 ` Fāng-ruì Sòng
2021-01-05 23:51 ` H.J. Lu
2021-01-06 0:50 ` Fāng-ruì Sòng
2021-01-06 1:43 ` H.J. Lu
2021-01-06 2:00 ` Fāng-ruì Sòng
2021-01-06 2:14 ` H.J. Lu
2021-01-05 22:57 ` Fāng-ruì Sòng
2021-01-08 5:04 ` Fāng-ruì Sòng
2021-01-08 17:09 ` H.J. Lu
2021-01-08 18:04 ` Fāng-ruì Sòng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFP8O3K3Bgzz=x61FGTqShCftGic2wi_x=Q6zoGioX4f4+BrBw@mail.gmail.com' \
--to=maskray@google.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).