[Bug gold/15200] Runtime undefined reference to __exidx_start/_end

[dougkwan at google dot com]

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
<address@hidden> 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.