http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #3 from pete <petechou at gmail dot com> 2013-03-07 02:39:59 UTC ---
Hello,
Let me describe this issue again. The runtime undefined reference is because:
1. Using ld.gold to link against libraries (say libc.so) in android ndk-r8, and
those libraries are probably generated by ld.bfd.
$ readelf -s /tmp/android-ndk-r8/platforms/android-14/arch-arm/usr/lib/libc.so
| grep exidx
106: 0000cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end
334: 0000cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start
730: 000089a8 20 FUNC GLOBAL DEFAULT 4 __gnu_Unwind_Find_exidx
118: 0000cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end
346: 0000cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start
742: 000089a8 20 FUNC GLOBAL DEFAULT 4 __gnu_Unwind_Find_exidx
2. Running the library on a newer version (say 4.2) of Android system, and
there are no __exidx_start/_end symbols in the libraries, e.g, libc.so.
$ readelf -s $AOSP/out/target/product/generic/system/lib/libc.so | grep exidx
882: 0000e929 4 FUNC GLOBAL DEFAULT 7 __gnu_Unwind_Find_exidx
891: 00000000 0 FUNC GLOBAL DEFAULT UND dl_unwind_find_exidx
So, it's fine to generate dynamic relocations for undefined symbols, but I
think section/segment symbols in output probably should be defined locally
anyway, if we're going to define them. Using section/segment definition in
DT_NEEDED doesn't seem to be the correct behavior?
BTW, I also checked ld.bfd also defines __exidx_start/_end locally.
$ arm-linux-androideabi-ld.bfd -shared -o libplasma.so plasma.o libc.so
$ readelf -s libplasma.so | grep exidx
3: 00003980 0 NOTYPE LOCAL DEFAULT ABS __exidx_end
4: 00003858 0 NOTYPE LOCAL DEFAULT ABS __exidx_start
64: 00000000 0 FUNC WEAK DEFAULT UND __gnu_Unwind_Find_exidx
119: 00003980 0 NOTYPE LOCAL DEFAULT ABS __exidx_end
121: 00003858 0 NOTYPE LOCAL DEFAULT ABS __exidx_start
185: 00000000 0 FUNC WEAK DEFAULT UND __gnu_Unwind_Find_exidx
Any comment about the issue and the patch?
-
Thanks,
Pete
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- 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
