From: "H.J. Lu" <hjl.tools@gmail.com>
To: "Fāng-ruì Sòng" <maskray@google.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH 0/3] Make glibc build with LLD
Date: Tue, 5 Jan 2021 17:43:46 -0800 [thread overview]
Message-ID: <CAMe9rOrjtf0KucwpUnWBUnvENz_H7YQbtjrr7zVajOxyVuNyjw@mail.gmail.com> (raw)
In-Reply-To: <CAFP8O3LiPsUTnkXOm=DEptoyTsEtckQph=jfqKeQ_xBtd5gO_g@mail.gmail.com>
On Tue, Jan 5, 2021 at 4:51 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Tue, Jan 5, 2021 at 3:52 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Jan 5, 2021 at 3:41 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > > >
> > > > > 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.
> > > >
> > > > 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 IFUNC at all
> > > > and so uses won't work, but a statically-linked program that 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 = 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 do
> > > > 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=48674
> >
> > --
> > H.J.
>
> I don't consider https://bugs.llvm.org/show_bug.cgi?id=48674 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 ld
> 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 =(ld.bfd --verbose) =(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 don't think they should be changed. lld
should follow my design.
--
H.J.
next prev parent reply other threads:[~2021-01-06 1:44 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
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 [this message]
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=CAMe9rOrjtf0KucwpUnWBUnvENz_H7YQbtjrr7zVajOxyVuNyjw@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=maskray@google.com \
/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).