* binutils causes GLIBC ifunc breakage on PowerPC64 ELFv2
@ 2014-08-17 14:10 Aurelien Jarno
2014-08-18 11:28 ` Alan Modra
0 siblings, 1 reply; 3+ messages in thread
From: Aurelien Jarno @ 2014-08-17 14:10 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
Hi,
Building GNU libc using binutils HEAD, I have noticed that the following
tests fails on PowerPC64 ELFv2:
| FAIL: elf/ifuncmain1staticpic
| FAIL: elf/ifuncmain4
| FAIL: elf/ifuncmain5staticpic
The last one segfault, while two first ones actually fails to build:
| gcc -nostdlib -nostartfiles -o /build/glibc/glibc-build/elf/ifuncmain4 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /build/glibc/glibc-build/csu/crt1.o /build/glibc/glibc-build/csu/crti.o `gcc --print-file-name=crtbegin.o` /build/glibc/glibc-build/elf/ifuncmain4.o -Wl,-dynamic-linker=/lib64/ld64.so.2 -Wl,-rpath-link=/build/glibc/glibc-build:/build/glibc/glibc-build/math:/build/glibc/glibc-build/elf:/build/glibc/glibc-build/dlfcn:/build/glibc/glibc-build/nss:/build/glibc/glibc-build/nis:/build/glibc/glibc-build/rt:/build/glibc/glibc-build/resolv:/build/glibc/glibc-build/crypt:/build/glibc/glibc-build/nptl /build/glibc/glibc-build/libc.so.6 /build/glibc/glibc-build/libc_nonshared.a -Wl,--as-needed /build/glibc/glibc-build/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed `gcc --print-file-name=crtend.o` /build/glibc/glibc-build/csu/crtn.o
| /build/glibc/toolchain/bin/ld: BFD (GNU Binutils) 2.24.51.20140817 internal error, aborting at elf64-ppc.c line 14483 in ppc64_elf_relocate_section
|Â
| /build/glibc/toolchain/bin/ld: Please report this bug.
|
| collect2: error: ld returned 1 exit status
| gcc -pie -Wl,-O1 -nostdlib -nostartfiles -o /build/glibc/glibc-build/elf/ifuncmain1vispie -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /build/glibc/glibc-build/csu/Scrt1.o /build/glibc/glibc-build/csu/crti.o `gcc --print-file-name=crtbeginS.o` /build/glibc/glibc-build/elf/ifuncmain1vispie.o /build/glibc/glibc-build/elf/ifuncmod1.so -Wl,-dynamic-linker=/lib64/ld64.so.2 -Wl,-rpath-link=/build/glibc/glibc-build:/build/glibc/glibc-build/math:/build/glibc/glibc-build/elf:/build/glibc/glibc-build/dlfcn:/build/glibc/glibc-build/nss:/build/glibc/glibc-build/nis:/build/glibc/glibc-build/rt:/build/glibc/glibc-build/resolv:/build/glibc/glibc-build/crypt:/build/glibc/glibc-build/nptl /build/glibc/glibc-build/libc.so.6 /build/glibc/glibc-build/libc_nonshared.a -Wl,--as-needed /build/glibc/glibc-build/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed `gcc --print-file-name=crtendS.o` /build/glibc/glibc-build/csu/crtn.o
| /build/glibc/toolchain/bin/ld: BFD (GNU Binutils) 2.24.51.20140817 internal error, aborting at elf64-ppc.c line 14483 in ppc64_elf_relocate_section
|
| /build/glibc/toolchain/bin/ld: Please report this bug.
|
| collect2: error: ld returned 1 exit status
Bisecting the issue I have found the problem has been introduced by this
commit:
| commit d1eca1e41ddae8c3cd925be827640de919301432
| Author: Alan Modra <amodra@gmail.com>
| Date: Wed Jul 2 15:07:18 2014 +0930
|
| Taking an undefined function's address in an executable
|
| doesn't always mean you need to define a function symbol on plt code.
| If all references are in read-write sections, then using dynamic relocs
| is OK.
|
| bfd/
| * elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Clear
| pointer_equality_needed when !readonly_dynrelocs.
| * elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Likewise.
| ld/testsuite/
| * ld-powerpc/ambiguousv1.d: Match symbol table too.
| * ld-powerpc/ambiguousv2.d: Likewise.
| * ld-powerpc/ambiguousv1b.d: New.
| * ld-powerpc/ambiguousv2b.d: New.
| * ld-powerpc/powerpc.exp: Run new tests.
Reverting this commit on top on current binutils HEAD makes the GNU libc
testsuite to pass. Do you have an idea what could be the problem? I
guess you will be able to reproduce by yourself, if not don't hesitate
to ask for more details.
Thanks,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: binutils causes GLIBC ifunc breakage on PowerPC64 ELFv2
2014-08-17 14:10 binutils causes GLIBC ifunc breakage on PowerPC64 ELFv2 Aurelien Jarno
@ 2014-08-18 11:28 ` Alan Modra
2014-08-18 12:05 ` Aurelien Jarno
0 siblings, 1 reply; 3+ messages in thread
From: Alan Modra @ 2014-08-18 11:28 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: binutils
On Sun, Aug 17, 2014 at 04:10:05PM +0200, Aurelien Jarno wrote:
> Bisecting the issue I have found the problem has been introduced by this
> commit:
>
> | commit d1eca1e41ddae8c3cd925be827640de919301432
> | Author: Alan Modra <amodra@gmail.com>
> | Date: Wed Jul 2 15:07:18 2014 +0930
> |
> | Taking an undefined function's address in an executable
> |
> | doesn't always mean you need to define a function symbol on plt code.
> | If all references are in read-write sections, then using dynamic relocs
> | is OK.
Thanks for tracking this down.
This probably could be fixed by making changes in relocate_section for
ifunc, but it's simpler to disable this optimisation for ifunc.
* elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Don't attempt to
use dynrelocs for ifunc.
* elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Similarly.
diff --git a/bfd/elf64-ppc.c b/bfd/elf64-ppc.c
index 0efc602..ca2dd4c 100644
--- a/bfd/elf64-ppc.c
+++ b/bfd/elf64-ppc.c
@@ -7002,6 +7002,7 @@ ppc64_elf_adjust_dynamic_symbol (struct bfd_link_info *info,
executable on a global entry stub. A dynamic reloc can
be used instead. */
if (h->pointer_equality_needed
+ && h->type != STT_GNU_IFUNC
&& !readonly_dynrelocs (h))
{
h->pointer_equality_needed = 0;
diff --git a/bfd/elf32-ppc.c b/bfd/elf32-ppc.c
index e20e804..97f4724 100644
--- a/bfd/elf32-ppc.c
+++ b/bfd/elf32-ppc.c
@@ -5512,9 +5512,12 @@ ppc_elf_adjust_dynamic_symbol (struct bfd_link_info *info,
{
/* Taking a function's address in a read/write section
doesn't require us to define the function symbol in the
- executable on a global entry stub. A dynamic reloc can
+ executable on a plt call stub. A dynamic reloc can
be used instead. */
if (h->pointer_equality_needed
+ && h->type != STT_GNU_IFUNC
+ && !htab->is_vxworks
+ && !ppc_elf_hash_entry (h)->has_sda_refs
&& !readonly_dynrelocs (h))
{
h->pointer_equality_needed = 0;
--
Alan Modra
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: binutils causes GLIBC ifunc breakage on PowerPC64 ELFv2
2014-08-18 11:28 ` Alan Modra
@ 2014-08-18 12:05 ` Aurelien Jarno
0 siblings, 0 replies; 3+ messages in thread
From: Aurelien Jarno @ 2014-08-18 12:05 UTC (permalink / raw)
To: binutils
On Mon, Aug 18, 2014 at 08:57:55PM +0930, Alan Modra wrote:
> On Sun, Aug 17, 2014 at 04:10:05PM +0200, Aurelien Jarno wrote:
> > Bisecting the issue I have found the problem has been introduced by this
> > commit:
> >
> > | commit d1eca1e41ddae8c3cd925be827640de919301432
> > | Author: Alan Modra <amodra@gmail.com>
> > | Date: Wed Jul 2 15:07:18 2014 +0930
> > |
> > | Taking an undefined function's address in an executable
> > |
> > | doesn't always mean you need to define a function symbol on plt code.
> > | If all references are in read-write sections, then using dynamic relocs
> > | is OK.
>
> Thanks for tracking this down.
>
> This probably could be fixed by making changes in relocate_section for
> ifunc, but it's simpler to disable this optimisation for ifunc.
>
> * elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Don't attempt to
> use dynrelocs for ifunc.
> * elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Similarly.
Thanks for the quick patch. I confirm it fixes the problem for elf64.
Unfortunately I don't have a full toolchain ready to test the elf32
case.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-08-18 12:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-17 14:10 binutils causes GLIBC ifunc breakage on PowerPC64 ELFv2 Aurelien Jarno
2014-08-18 11:28 ` Alan Modra
2014-08-18 12:05 ` Aurelien Jarno
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).