https://sourceware.org/bugzilla/show_bug.cgi?id=22269
--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Alan Modra from comment #4)
> I agree that undefined weak symbols probably ought to resolve to 0 in a
> static PIE. To do that on ppc it would be reasonable to add the following
> to elf32.em after_parse
>
> if (link_info.dynamic_undefined_weak == -1
> && link_info.nointerp)
> link_info.dynamic_undefined_weak = FALSE;
For powerpc, I got
[hjl@gnu-efi-2 pr22263]$ cat x.c
__thread int * foo;
void
bar (void)
{
*foo = 1;
}
[hjl@gnu-efi-2 pr22263]$ cat y.c
extern __thread int *foo;
static int x;
extern void bar (void);
int
_start ()
{
foo = &x;
return 0;
}
[hjl@gnu-efi-2 pr22263]$ make
/export/gnu/import/git/toolchain/install/compilers/powerpc-linux-gnu/bin/powerpc-glibc-linux-gnu-gcc
-fPIE -O2 -c -o x.o x.c
/export/gnu/import/git/toolchain/install/compilers/powerpc-linux-gnu/bin/powerpc-glibc-linux-gnu-gcc
-fPIE -O2 -c -o y.o y.c
./ld -pie -o x x.o y.o
readelf -rW x
Relocation section '.rela.dyn' at offset 0x1ac contains 1 entries:
Offset Info Type Sym. Value Symbol's Name + Addend
0001ff68 00000016 R_PPC_RELATIVE 20000
[hjl@gnu-efi-2 pr22263]$
There should be no dynamic relocations.
> or perhaps something a little more specific to static PIE..
>
> However, that results in
> FAIL: ld-i386/pr19636-1d
> FAIL: ld-i386/pr19636-1e
> FAIL: ld-i386/pr19636-1f
> FAIL: ld-x86-64/pr19636-2d
> FAIL: ld-x86-64/pr19636-2e
> FAIL: ld-x86-64/pr19636-2f
>
> So, why does x86 make undefined weak symbols dynamic in the -d tests (which
> are -pie --no-dynamic-linker)?
With your patch, I got
[hjl@gnu-efi-2 ld]$ cat
/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/ld-x86-64/pr19636-2.s
.text
.weak func1
.weak func2
.weak func3
.globl _start
_start:
cmp func1@GOTPCREL(%rip),%rax
jmp *func2@GOTPCREL(%rip)
call func3@PLT
[hjl@gnu-efi-2 ld]$ cat 1
/export/build/gnu/binutils/build-x86_64-linux/ld/../gas/as-new --64
-mrelax-relocations=no -o tmpdir/pr19636-2.o
/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/ld-x86-64/pr19636-2.s
./ld-new -z norelro
-L/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/ld-x86-64 -pie -m
elf_x86_64 --no-dynamic-linker --hash-style=sysv -o tmpdir/dump
tmpdir/pr19636-2.o
/export/build/gnu/binutils/build-x86_64-linux/ld/../binutils/objdump -dw
tmpdir/dump
[hjl@gnu-efi-2 ld]$ sh 1
tmpdir/dump: file format elf64-x86-64
Disassembly of section .text:
0000000000000111 <_start>:
111: 48 3b 05 e0 00 20 00 cmp 0x2000e0(%rip),%rax # 2001f8
<.got>
118: ff 25 e2 00 20 00 jmpq *0x2000e2(%rip) # 200200
<.got+0x8>
11e: e8 dd fe ff ff callq 0 <_start-0x111>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Since call is PC relative, this doesn't branch to address 0.
[hjl@gnu-efi-2 ld]$ ld -z norelro
-L/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/ld-x86-64 -pie -m
elf_x86_64 --no-dynamic-linker --hash-style=sysv -o tmpdir/dump
tmpdir/pr19636-2.o
[hjl@gnu-efi-2 ld]$ objdump -dw tmpdir/dump
tmpdir/dump: file format elf64-x86-64
Disassembly of section .plt:
0000000000000120 <.plt>:
120: ff 35 2a 01 20 00 pushq 0x20012a(%rip) # 200250
<_GLOBAL_OFFSET_TABLE_+0x8>
126: ff 25 2c 01 20 00 jmpq *0x20012c(%rip) # 200258
<_GLOBAL_OFFSET_TABLE_+0x10>
12c: 0f 1f 40 00 nopl 0x0(%rax)
130: ff 25 2a 01 20 00 jmpq *0x20012a(%rip) # 200260
<_GLOBAL_OFFSET_TABLE_+0x18>
136: 68 00 00 00 00 pushq $0x0
13b: e9 00 00 00 00 jmpq 140 <_start>
Disassembly of section .text:
0000000000000140 <_start>:
140: 48 3b 05 f1 00 20 00 cmp 0x2000f1(%rip),%rax # 200238
<.got>
147: ff 25 f3 00 20 00 jmpq *0x2000f3(%rip) # 200240
<.got+0x8>
14d: e8 de ff ff ff callq 130 <.plt+0x10>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This branches to the PLT entry which branches to address 0 via indirect
GOT branch.
[hjl@gnu-efi-2 ld]$
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
