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,sd_get_seats@LIBSYSTEMD_209");
> 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:
[hjl@gnu-tools-1 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
[hjl@gnu-tools-1 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
[hjl@gnu-tools-1 pr16467]$
--
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
