On Sunday 25 March 2012 17:52:51 Khem Raj wrote:
> On Sun, Mar 25, 2012 at 12:42 PM, Joakim Tjernlund wrote:
> > Khem Raj <raj.k...@gmail.com> wrote on 2012/03/25 20:23:04:
> >> On Sun, Mar 25, 2012 at 10:30 AM, Joakim Tjernlund wrote:
> >> >> On Sun, Mar 25, 2012 at 12:58 AM, Mike Frysinger wrote:
> >> >> > On Sunday 25 March 2012 03:23:38 Khem Raj wrote:
> >> >> >> On Sat, Mar 24, 2012 at 11:58 PM, Mike Frysinger wrote:
> >> >> >> > The _start symbol is the default entry point for ELFs, so there
> >> >> >> > should be no need to manually specify this.  The background
> >> >> >> > motivation is that this causes issues for ports that have a
> >> >> >> > symbol prefix (like Blackfin) and so they don't have a "_start"
> >> >> >> > symbol -- it's named "__start".
> >> >> >> 
> >> >> >> on MIPS its also __start unlike others where it is _start
> >> >> > 
> >> >> > ok, i'll ponder exposing __USER_LABEL_PREFIX__ to the build system
> >> >> > somehow then so it automatically selects the right "_start"
> >> >> 
> >> >> if binutils/ld is configured for right emulation (which it should be)
> >> >> that should take care of it automatically
> >> >> though so your patch is ok.
> >> > 
> >> > I think the problem is that ldso.c expects start to be named _start so
> >> > you can't just rename it __start.
> >> > You could define _start = __start in arch code that need it though.
> >> 
> >> isnt it arch specific function in ldso/<arch>/dl-startup.h ?
> > 
> > It is in ldso/ldso/ldso.c last I checked.
> 
> right thats the consumer of the definition so I think adding alias for
> __start in the definition will fix this problem.

it should be easy to add aliases via .set for both mips and blackfin (and prob 
h8300, although that doesn't have a ldso port) so _start == __start.  i don't 
think there would be runtime penalties for this as long as the symbol has 
hidden visibility.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Reply via email to