http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #8 from Doug Kwan 2013-03-07 08:10:16
UTC ---
Hi Pete,
1. My concern of your patch is that it affects all targets, not just
ARM. While it may fix the problem on ARM, I cannot speak for authors
of other backends.
2. I am don't have power approve a patch, you need to convince Ian
Taylor that this is the right thing to do for all targets.
3. This bug only happens when DSOs incorrectly export __exidx_start &
__exidx_end. These DSOs are considered broken and I strongly
recommend you moving to a newer NDK version with DSOs that have proper
visibility. Both ld & gold no longer export these symbols. The
reason for not exporting is explained here in the ld patch:
http://sourceware.org/ml/binutils/2009-11/msg00367.html
-Doug
On Wed, Mar 6, 2013 at 10:43 PM, petechou at gmail dot com
wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>
> --- Comment #7 from pete 2013-03-07 06:43:08 UTC
> ---
> I can think visibility does matter, but only for exporting the symbol or not.
> In the previous case, gold does define the __bss symbols but not use the
> definition in DSO, so I think we should still define section/segment symbols
> locally.
>
> -Pete
>
> (In reply to comment #6)
>> The symbols do not have same visibility. gold in general is
>> compatible with GNU ld. If you look at src/ld/emulparams/, you will
>> set that the __bss symbols are exported but the __exidx symbols are
>> defined hidden. gold matches the behaviour of ld. If you look at
>> defstd.cc in gold, you will again see that some of these symbols are
>> hidden but some are not.
>>
>> -Doug
>>
>>
>> On Wed, Mar 6, 2013 at 9:31 PM, petechou at gmail dot com
>> wrote:
>> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200
>> >
>> > --- Comment #5 from pete 2013-03-07 05:31:25
>> > UTC ---
>> > (In reply to comment #4)
>> >> 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.
>> >
>> > If so, all section/segment symbols should be defined (if needed) by not
>> > exported?
>> >
>> > But when there is a non-weak definition in a DSO, it's still possible to
>> > find
>> > ld.gold define and export segment symbols like __bss_start (See
>> > gold.defstd.cc:214. only_if_ref is set to false). And there is no multiple
>> > definition error.
>> >
>> > $ readelf -Ds libc.so | grep __bss_start
>> > 268 311: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__
>> > 619 470: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
>> >
>> > $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so
>> >
>> > $ readelf -s libplasma.so | grep __bss_start
>> > 73: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
>> >168: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
>> >
>> >> 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?
>> >>
>> >
>> > Yes, there is no this issue with the latest NDK.
>> >
>> > -
>> > 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.
--
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
