Message ID | 20201228194855.510315-1-maskray@google.com |
---|---|
Headers | show |
Series | Make glibc build with LLD | expand |
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 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.
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. >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.
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. > >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?
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.
On Mon, Dec 28, 2020 at 1:50 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. > > > >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? > > -- > H.J. "Make _dl_relocate_static_pie return an int indicating whether it applied relocs." makes glibc build with both GNU ld and LLD. Without the commit, elf/ldconfig segfaults with LLD but works with GNU ld because the code relies on the undefined weak __rela_iplt_start/__rela_iplt_end to be null. % ld.bfd --verbose | grep rela_iplt_start PROVIDE_HIDDEN (__rela_iplt_start = .); % ld.bfd -pie --verbose | grep rela_iplt_start % ld.bfd -shared --verbose | grep rela_iplt_start I don't think this justifies a different behavior in ld.
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.
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.
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.
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
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.
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.
On Tue, Jan 5, 2021 at 5:44 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > 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 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
On Tue, Jan 5, 2021 at 6:00 PM Fāng-ruì Sòng <maskray@google.com> wrote: > > On Tue, Jan 5, 2021 at 5:44 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > 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 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=48674
On Mon, Dec 28, 2020 at 11:48 AM Fangrui Song <maskray@google.com> 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. > > Fangrui Song (3): > configure: Allow LD to be a linker other than GNU ld and gold > elf: Replace a --defsym trick with an object file to be compatible > with lld > install: Replace scripts/output-format.sed with objdump -f > > Makerules | 13 ++----- > .../strcoll-inputs/filelist#en_US.UTF-8 | 1 - > config.make.in | 1 - > configure | 32 +++++------------ > configure.ac | 24 +++++-------- > elf/Makefile | 11 +++--- > scripts/output-format.sed | 35 ------------------- > 7 files changed, 23 insertions(+), 94 deletions(-) > delete mode 100644 scripts/output-format.sed > > -- > 2.29.2.729.g45daf8777d-goog > Hope "elf:" and "install:" can be reviewed (they are nice simplification on their own), even if you don't want to take "configure:" for now. For __rela_iplt_start, I gave a fair assessment on https://bugs.llvm.org/show_bug.cgi?id=48674#c4 . I feel bad that an improvable binutils issue caused the block of a static-pie relocation improvement "Make _dl_relocate_static_pie return an int indicating whether it applied relocs." The other few failures (e.g. not supporting ld.lld --audit / tls common) are not really usability affecting issues.
On Thu, Jan 7, 2021 at 9:05 PM Fāng-ruì Sòng via Libc-alpha <libc-alpha@sourceware.org> wrote: > > On Mon, Dec 28, 2020 at 11:48 AM Fangrui Song <maskray@google.com> 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. > > > > Fangrui Song (3): > > configure: Allow LD to be a linker other than GNU ld and gold > > elf: Replace a --defsym trick with an object file to be compatible > > with lld > > install: Replace scripts/output-format.sed with objdump -f > > > > Makerules | 13 ++----- > > .../strcoll-inputs/filelist#en_US.UTF-8 | 1 - > > config.make.in | 1 - > > configure | 32 +++++------------ > > configure.ac | 24 +++++-------- > > elf/Makefile | 11 +++--- > > scripts/output-format.sed | 35 ------------------- > > 7 files changed, 23 insertions(+), 94 deletions(-) > > delete mode 100644 scripts/output-format.sed > > > > -- > > 2.29.2.729.g45daf8777d-goog > > > > Hope "elf:" and "install:" can be reviewed (they are nice > simplification on their own), even if you don't want to take > "configure:" for now. > > For __rela_iplt_start, I gave a fair assessment on > https://bugs.llvm.org/show_bug.cgi?id=48674#c4 . I feel bad that an > improvable binutils issue caused the block of a static-pie relocation > improvement No. There is no need to work around the lld bug which can be fixed. > "Make _dl_relocate_static_pie return an int indicating whether it > applied relocs." The other few failures (e.g. not supporting ld.lld > --audit / tls common) are not really usability affecting issues. "make check" should be clean. Otherwise, we have no way to know if glibc is built properly on x86.
On Fri, Jan 8, 2021 at 9:10 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Thu, Jan 7, 2021 at 9:05 PM Fāng-ruì Sòng via Libc-alpha > <libc-alpha@sourceware.org> wrote: > > > > On Mon, Dec 28, 2020 at 11:48 AM Fangrui Song <maskray@google.com> 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. > > > > > > Fangrui Song (3): > > > configure: Allow LD to be a linker other than GNU ld and gold > > > elf: Replace a --defsym trick with an object file to be compatible > > > with lld > > > install: Replace scripts/output-format.sed with objdump -f > > > > > > Makerules | 13 ++----- > > > .../strcoll-inputs/filelist#en_US.UTF-8 | 1 - > > > config.make.in | 1 - > > > configure | 32 +++++------------ > > > configure.ac | 24 +++++-------- > > > elf/Makefile | 11 +++--- > > > scripts/output-format.sed | 35 ------------------- > > > 7 files changed, 23 insertions(+), 94 deletions(-) > > > delete mode 100644 scripts/output-format.sed > > > > > > -- > > > 2.29.2.729.g45daf8777d-goog > > > > > > > Hope "elf:" and "install:" can be reviewed (they are nice > > simplification on their own), even if you don't want to take > > "configure:" for now. > > > > For __rela_iplt_start, I gave a fair assessment on > > https://bugs.llvm.org/show_bug.cgi?id=48674#c4 . I feel bad that an > > improvable binutils issue caused the block of a static-pie relocation > > improvement > > No. There is no need to work around the lld bug which can be fixed. I wish the glibc change does not make people feel "oh, we change glibc just to adapt LLD". I have provided my reasoning (https://sourceware.org/bugzilla/show_bug.cgi?id=27164) why this is not an LLD bug and I believe the reasoning is pretty solid (drop a gratuitous difference between ld and ld -pie; clarify glibc code). This is both a (future) cleanup opportunity for GNU ld and a clarification for glibc csu/libc-start.c > > "Make _dl_relocate_static_pie return an int indicating whether it > > applied relocs." The other few failures (e.g. not supporting ld.lld > > --audit / tls common) are not really usability affecting issues. > > "make check" should be clean. Otherwise, we have no way to > know if glibc is built properly on x86. > > -- > H.J.