[Bug ld/16467] ld fails with internal error in elf_x86_64_relocate_section when .symver and ifunc magic is used

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16467



--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---

(In reply to Zbigniew Jędrzejewski-Szmek from comment #7)

> > Can you double check if gold generates the working output?

> It seemed to be working for me before, in the sense that at least linking

> worked without any error report, and the binary linking the symbols in the

> equivalent of libb in the example above was running successfully. I didn't

> actually test whether the functions can be correctly called. Updated reci
pe

> that I paste below does that. I use versioned symbols for libb.so too.

> Without that, resulting binary segfaults when it is run.

> Also, I had to added -fPIC to the compilation of liba.so. Previously I

> tested with both gcc-4.7 and gcc-4.8, and the old gcc did not complain ab
out

> missing -fPIC, the newer one does. The guess the newer one is right.

> 

> --------------------------------------------------

> ==> liba.c <==

> const char* sd_get_seats(void) {return "bla bla";}

> 

> ==> liba.sym <==

> LIBSYSTEMD_209 {

> global:

>         sd_get_seats;

> };

> 

> ==> libb.c <==

> void new_sd_get_seats(void);

> __asm__(".symver new_sd_get_seats,address@hidden");

> static void (*resolve_sd_get_seats(void)) (void) {

>         return new_sd_get_seats;

> }

> void sd_get_seats(void) __attribute__((ifunc("resolve_sd_get_seats")));

> 

> ==> libb.sym <==

> LIBSYSTEMD_208 {

> global:

>         sd_get_seats;

> };

> 

> ==> test1.c <==

> #include <stdio.h>

> const char* sd_get_seats(void);

> 

> int main(int argc, char **argv) {

>         printf("%s\n", sd_get_seats());

>         return 0;

> }

> $ gcc -shared -o liba.so liba.c -Wl,--version-script=liba.sym

> -Wl,-fuse-ld=gold -fPIC        

> $ gcc -shared -fPIC libb.c -o libb.so -L. -la -Wl,-fuse-ld=gold

> -Wl,--version-script=libb.sym

> $ gcc -L. -lb -Wl,-fuse-ld=gold test1.c -o test1       
                     

> 

> $ LD_LIBRARY_PATH=. ./test1

> bla bla

> 

> $ LD_LIBRARY_PATH=. ldd ./test1

>         linux-vdso.so.1 (0x00007fff81963000)

>         libb.so => ./libb.so (0x00007faf96c52000)

>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faf9687200
0)

>         liba.so => ./liba.so (0x00007faf9686f000)

>         /lib64/ld-linux-x86-64.so.2 (0x00007faf96c56000)



This is a different testcase since there is an additional

-Wl,--version-script=libb.sym.  My patch works correctly.

Please make sure that you are using the new linker with

my patch against the current binutils master branch:



address@hidden pr16467]$ make

gcc -B./ -fPIC -g   -c -o test1.o test1.c

gcc -B./ -fPIC -g   -c -o libb.o libb.c

gcc -B./ -fPIC -g   -c -o liba.o liba.c

gcc -B./  -shared -o liba.so liba.o -Wl,--version-script=liba.sym

gcc -B./  -shared -o libb.so libb.o liba.so -Wl,--version-script=libb.sym

gcc -B./  -o test1 test1.o libb.so liba.so -Wl,-rpath,. #-Wl,-z,now

./test1

bla bla

address@hidden pr16467]$ gcc -B./  -o test1 test1.o libb.so liba.so

-Wl,-rpath,. -Wl,-v

collect2 version 4.8.2 20140115 (Red Hat 4.8.2-11)

./ld --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x8
6_64

-dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test1

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crti.o

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/crtbegin.o -L.

-L/usr/lib/gcc/x86_64-redhat-linux/4.8.2

-L/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64 -L/lib/../lib64

-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../.. test1
.o

libb.so liba.so -rpath . -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -l
gcc

--as-needed -lgcc_s --no-as-needed

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/crtend.o

/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crtn.o

GNU ld (GNU Binutils) 2.24.51.20140118

address@hidden pr16467]$



-- 

You are receiving this mail because:

You are on the CC list for the bug.