http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #11 from pete <petechou at gmail dot com> 2013-03-20 02:04:21 UTC --- Hello Ian, Would you please comment on the issue and patch? - Thanks, Pete (In reply to comment #10) > I have no object to what is proposed but the decision is Ian's. > > On Tue, Mar 12, 2013 at 7:03 PM, petechou at gmail dot com > <sourceware-bugzi...@sourceware.org> wrote: > > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > > > > --- Comment #9 from pete <petechou at gmail dot com> 2013-03-13 02:03:32 > > UTC --- > > If there is a libfoo.so, it's possible to implement part of functions in > > libfoo.so and then link against libfoo.so again to produce a new library. I > > think the "linker-defined" symbols should also have higher priority than the > > symbols in DSO. > > > > And I also think we should have the same behavior on defining symbol value > > whether only_if_ref is set or not? > > > > The patch will affect 4 ways to define output symbols: > > 1. do_define_in_output_data > > 2. do_define_in_output_segment > > 3. do_define_as_constant > > 4. add_undefined_symbol_from_command_line > > > > For 1, 2, and 3, it makes sense to use the given output section, segment, > > and > > constant to define symbol values if the "linker-defined" symbols have higher > > priority. > > > > As for 4, I think it doesn't matter. > > > > - > > Thanks, > > Pete > > > > (In reply to comment #8) > >> 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 > >> <sourceware-bugzi...@sourceware.org> wrote: > >> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > >> > > >> > --- Comment #7 from pete <petechou at gmail dot com> 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 > >> >> <sourceware-bugzi...@sourceware.org> wrote: > >> >> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > >> >> > > >> >> > --- Comment #5 from pete <petechou at gmail dot com> 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: 0000d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__ > >> >> > 619 470: 0000d898 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: 00004148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > >> >> > 168: 00004148 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. -- 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
