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

[petechou at gmail dot com]

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