From: "H.J. Lu" <hjl.tools@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Fangrui Song <maskray@google.com>,
Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: lld status with powerpc64
Date: Fri, 5 Nov 2021 12:38:58 -0700 [thread overview]
Message-ID: <CAMe9rOp7ohS_PLTPAi14qq3GT-YVZ5Mz661jZDi=fQzZ3nG=aw@mail.gmail.com> (raw)
In-Reply-To: <e53b265a-589a-64a2-52f3-4261632f5d9f@linaro.org>
On Fri, Nov 5, 2021 at 12:33 PM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> On 05/11/2021 10:58, Adhemerval Zanella wrote:
>
> > So we have two options here:
> >
> > 1. Do not define USE_PPC64_NOTOC if with-lld (not optimal if ldd
> > aims to support such behavior).
> >
> > 2. Define USE_PPC64_NOTOC iff linker supports such optimization.
> > It means to emit a NOTOC relocation (R_PPC64_REL24_NOTOC),
> > link a simple binary without any pcrel and check if the stub has
> > power10 instruction.
> >
> > 3. Remove the USE_PPC64_NOTOC usage. It is used on setjmp routines
> > and on the syscall definition to call the __syscall_error.
> >
> > I am aiming to implement 2. since at least by disabling USE_PPC64_NOTOC
> > manually on config.h when configuring with lld I can build glibc.
> >
> >>
> >>
> >> In my testing environment (POWER9), ld.bfd doesn't support @notoc, so
> >> USE_PPC64_NOTOC is undefined.
> >>
> >> % gcc --version
> >> gcc (Debian 8.3.0-6) 8.3.0
> >> ...
> >> % ld.bfd --version
> >> GNU ld (GNU Binutils for Debian) 2.31.1
> >> ...
> >>
> >> I only see 8 more FAILs with ld.lld than ld.bfd
> >
> > I am still having trouble to *finish* make check with lld release 13
> > my environment (some tests stuck on infinite loop).
> >
> >>
> >>
> >> % diff -u 0 1
> >> --- 0 2021-11-05 00:11:43.218731302 -0700
> >> +++ 1 2021-11-05 00:11:37.659286448 -0700
> >> @@ -9,6 +9,14 @@
> >> FAIL: debug/tst-lfschk6
> >> FAIL: dlfcn/bug-atexit3
> >> FAIL: elf/check-abi-libc
> >> +FAIL: elf/ifuncmain1pic
> >> +FAIL: elf/ifuncmain1pie
> >> +FAIL: elf/ifuncmain1vis
> >> +FAIL: elf/ifuncmain1vispic
> >> +FAIL: elf/ifuncmain1vispie
> >> +FAIL: elf/ifuncmain3
> >> +FAIL: elf/ifuncmain6pie
> >> +FAIL: elf/tst-tlsopt-powerpc
> >> FAIL: nptl/tst-cancel24
> >> FAIL: nptl/tst-minstack-throw
> >> FAIL: nptl/tst-once5
> >>
> >>
> >> I suspect ifuncmain1* is again related to the order of R_*_IRELATIVE with
> >> regard to R_*_JUMP_SLOT referencing a STT_GNU_IFUNC symbol.
> >> (something like https://maskray.me/blog/2021-01-18-gnu-indirect-function#relocation-resolving-order)
> >> But perhaps Adhemerval can look a look at it.
> >
> > I still need to understand why armhf also fails with the ifunc using
> > protected symbols, although I am not if they are related to IRELATIVE
> > ordering.
> >
> >>
> >>
> >> For elf/tst-tlsopt-powerpc, it is simply because ld.lld doesn't implement the GNU ld powerpc64's
> >> __tls_get_addr_opt (pseudo-TLSDESC): https://maskray.me/blog/2021-02-14-all-about-thread-local-storage#powerpc-__tls_get_addr_opt
> >> Let me send a configure patch to disable it...
> >>
> >> Actually I do not know how to disable tst-tlsopt-powerpc properly.
> >>
> >> Perhaps add sysdeps/powerpc/configure.ac and move the
> >> sysdeps/unix/sysv/linux/powerpc/configure.ac --no-tls-get-addr-optimize
> >> to sysdeps/powerpc/configure.ac?
> >> sysdeps/powerpc/preconfigure.ac exists (I don't know how it is used).
> >>
> >> The patch requires some non-trivial configure.ac change, so I'd hope
> >> that an expert can do it
> >
> > Maybe just disable the test if __tls_get_addr_opt (pseudo-TLSDESC) is not supported
> > by the linker?
> >
> >
> >>
> >>
> >> Hey, so lld linked glibc powerpc64 is in a pretty good status!
> >
> > I am still not sure about it, I did could run some tests but I am still
> > struggling to get a make check to finish.
> >
>
> So it turned out the another issues was my gcc toolchain did not have
> initfini array set which lets to compiler generate .ctors instead of
> .init_array and lld does not support .ctors (it just ignores instead of
> converting to .init_array entries as bfd).
>
> With NOTOC fix and a proper toolchain I am seeing the same regression
> you are seeing:
>
> FAIL: elf/ifuncmain1pic
> FAIL: elf/ifuncmain1pie
> FAIL: elf/ifuncmain1vis
> FAIL: elf/ifuncmain1vispic
> FAIL: elf/ifuncmain1vispie
> FAIL: elf/ifuncmain3
> FAIL: elf/ifuncmain6pie
> FAIL: elf/tst-tlsopt-powerpc
>
> I think it would be good use --enable-initfini-array on build-many-glibc.py
> until we set gcc-12 as default.
https://sourceware.org/pipermail/libc-alpha/2021-June/127413.html
--
H.J.
next prev parent reply other threads:[~2021-11-05 19:39 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-26 20:03 [PATCH 0/3] Improve lld support and current status Adhemerval Zanella
2021-10-26 20:03 ` [PATCH 1/3] elf: Disable ifuncmain{1,5,5pic,5pie} when using LLD Adhemerval Zanella
2021-10-29 19:49 ` Fangrui Song
2021-10-26 20:03 ` [PATCH 2/3] Fix LIBC_PROG_BINUTILS for -fuse-ld=lld Adhemerval Zanella
2021-10-26 20:48 ` Fangrui Song
2021-10-27 11:42 ` Adhemerval Zanella
2021-10-26 20:03 ` [PATCH 3/3] Check if linker also support -mtls-dialect=gnu2 Adhemerval Zanella
2021-10-27 2:04 ` Fāng-ruì Sòng
2021-10-29 0:56 ` Fāng-ruì Sòng
2021-10-26 20:33 ` [PATCH 0/3] Improve lld support and current status Fangrui Song
2021-10-27 13:11 ` Adhemerval Zanella
2021-10-28 1:06 ` Fangrui Song
2021-10-28 1:18 ` Fangrui Song
2021-10-28 17:40 ` Adhemerval Zanella
2021-10-28 11:48 ` Adhemerval Zanella
2021-10-27 22:39 ` Tulio Magno Quites Machado Filho
2021-10-27 22:50 ` Tulio Magno Quites Machado Filho
2021-11-05 7:23 ` lld status with powerpc64 Fangrui Song
2021-11-05 7:45 ` Fangrui Song
2021-11-05 13:58 ` Adhemerval Zanella
2021-11-05 19:32 ` Adhemerval Zanella
2021-11-05 19:38 ` H.J. Lu [this message]
2021-11-05 19:40 ` H.J. Lu
2021-11-05 19:50 ` Fāng-ruì Sòng
2021-11-07 14:24 ` Bill Schmidt
2021-11-08 11:37 ` Adhemerval Zanella
2021-11-08 13:26 ` Bill Schmidt
2021-11-08 13:54 ` Adhemerval Zanella
2021-11-08 13:59 ` Bill Schmidt
2021-11-08 14:11 ` Adhemerval Zanella
2021-11-08 14:12 ` Bill Schmidt
[not found] ` <OFD215FC7A.323066CE-ON00258787.0051DA95-00258787.00532945@ibm.com>
2021-11-08 22:38 ` Fangrui Song
2021-11-09 12:20 ` Adhemerval Zanella
2021-10-27 23:37 ` [PATCH 0/3] Improve lld support and current status Fangrui Song
2021-10-28 17:27 ` Tulio Magno Quites Machado Filho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMe9rOp7ohS_PLTPAi14qq3GT-YVZ5Mz661jZDi=fQzZ3nG=aw@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=maskray@google.com \
--cc=tuliom@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).