mbox series

[0/3] Make glibc build with LLD

Message ID 20201228194855.510315-1-maskray@google.com
Headers
Series Make glibc build with LLD |

Message

Fangrui Song Dec. 28, 2020, 7:48 p.m. UTC 
  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

Comments

H.J. Lu Dec. 28, 2020, 9:11 p.m. UTC | #1 
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.
Fangrui Song Dec. 28, 2020, 9:45 p.m. UTC | #2 
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.
H.J. Lu Dec. 28, 2020, 9:49 p.m. UTC | #3 
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. Lu Dec. 28, 2020, 10:54 p.m. UTC | #4 
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.
Fangrui Song Jan. 5, 2021, 10:57 p.m. UTC | #5 
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.
Fangrui Song Jan. 5, 2021, 11:03 p.m. UTC | #6 
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.
H.J. Lu Jan. 5, 2021, 11:33 p.m. UTC | #7 
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.
Fangrui Song Jan. 5, 2021, 11:41 p.m. UTC | #8 
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.
H.J. Lu Jan. 5, 2021, 11:51 p.m. UTC | #9 
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
Fangrui Song Jan. 6, 2021, 12:50 a.m. UTC | #10 
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.
H.J. Lu Jan. 6, 2021, 1:43 a.m. UTC | #11 
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.
Fangrui Song Jan. 6, 2021, 2 a.m. UTC | #12 
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
H.J. Lu Jan. 6, 2021, 2:14 a.m. UTC | #13 
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
Fangrui Song Jan. 8, 2021, 5:04 a.m. UTC | #14 
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.
H.J. Lu Jan. 8, 2021, 5:09 p.m. UTC | #15 
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.
Fangrui Song Jan. 8, 2021, 6:04 p.m. UTC | #16 
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.