https://sourceware.org/bugzilla/show_bug.cgi?id=33237
--- Comment #10 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> Why does Solaris have a different value?
I've reduced the testcase a bit as seen in the new attachment.
When I compile it like
gcc -c -fPIE main1.c
gcc -c check1.S
gcc -Bld/ -o 1f-1 -pie check1.o main1.o -R . libno-plt-1a.so libno-plt-1b.so
-Wl,-rpath,.,--no-warn-execstack
gcc -c -fPIE -O1 -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables
-fomit-frame-pointer -fno-plt -save-temps check2.c
gcc -Bld/ -o 1f-2 -pie check2.o main1.o -R . libno-plt-1a.so libno-plt-1b.so
-Wl,-rpath,.,--no-warn-execstack
(with ld a symlink to the current ld/tmpdir/ld directory) and
libno-plt-1?.so also symlinks to the original objects.
There's what I find:
* On Linux/x86_64, both 1f-1 and 1f-2 run successfully.
* On Solaris/amd64, 1f-1 aborts, while 1f-2 works.
Also, in gdb func_p is 0x0 in 1f-1.
Comparing check1.S and check2.s, there's no difference on Linux/x86_64
while on Solaris/amd64 there's
check:
subq $8, %rsp
call *get_func@GOTPCREL(%rip)
- cmpq %rax, func_p(%rip)
+ movq func_p@GOTPCREL(%rip), %rdx
+ cmpq %rax, (%rdx)
So gcc generates different code in this case. No idea why, though.
--
You are receiving this mail because:
You are on the CC list for the bug.
