[PATCH 0/3] Make glibc build with LLD

Tue Jan 5 23:41:07 GMT 2021

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.