http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #4 from Doug Kwan <dougkwan at google dot com> 2013-03-07 04:04:35 UTC --- The symbols __exidx_end & __exidx_start were exported incorrectly in the past. This is fixed in both ld & gold in the sense that these symbols are defined by not exported. I think defining these symbols when there is a non-weak definition in a DSO is not the right thing to do. This is basically multiple definition and usually is an error. I am not working on the Android NDK so I can't give you a good suggestion here. Does using the latest NDK fixes your problem? On Wed, Mar 6, 2013 at 6:39 PM, petechou at gmail dot com <sourceware-bugzi...@sourceware.org> wrote: > 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. -- 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