[uClibc]Shared libs, ARM

[Shane Nay]

> Actually it is, but it is on a separate branch, and it is a little out of
> date, since I didn't know anybody else was looking at it yet.  Anyways, the
> ARM stuff lives on a branch in CVS (since without this stuff shared libs do
> work on ARM -- you just end up using glibcs amazingly huge shared lib
> loader).
>
> To get the ARM stuff:
> 	cd ldso/d-link
> 	cvs up -r ARM_LDSO_SUPPORT
> and you will be working with the latest junk that I have been toying
> with...

Cool thanks.

> > /home2/guest/shane at minirl.com/ ), but it seems to be blowing a fuse with
> > the .data section or something.  Basically the SEND_STDERR macro is
> > blowing a fuse on ARM.  (Even with optimization turned on)  I think I did
> > all the ARM stuff mostly correctly (d-link/arm/), but now I'm trying to
> > test it and coming up with this nasty little problem.
> >
> > Anyone have any ideas?  I'm going to look at it more closely tomorrow and
> > see what I can come up with.  It's probably looking in the wrong place
> > for the data section.  (It comes up as a null pointer in the inlined
> > dl_strlen function for the very first character)
>
> I ran in to just this problem earlier this week.  When I put some code like
>     _dl_write(2, "hello\n", 6);
>     _dl_exit(42);
> right at the beginning of boot1.c, this is what strace showed on my
> NetWinder (that is what I use for doing ARM development -- it is a
> strongArm (sa-110))
>
>     [andersen at winder d-link]$ strace ~/CVS/uClibc/test/args/arg_test
>     execve("test/args/arg_test", ["test/args/arg_test"], [/* 33 vars */]) =
> 0 write(2, ptrace: umoven: Input/output error
>     0x5a60, 6)                     = -1 EFAULT (Bad address)
>
> Now clearly address 0x5a60 is not mapped into our apps address space --  it
> really should be something like 0x40005a60.  So what is happening is that
> with a construct like the compiler on ARM is placing the static string
> ("hello\n") into the symbol table -- so we can't reference it until we fix
> up its address.
>
> So we need to be able to find where the strings are being relocated to.

Yes, there is a really hacky way, like...

#define get_pc()  asm("mov r0, pc")
unsigned int m;
some_label:
m=get_pc();
m-= (unsigned long)&some_label;
m>>=10;  /* Really just detainting.  PAGE_SIZE is probably best */
m<<=10;
load_addr+=m;

Putting this into SEND_STDERR would allow us to print in the loader I'm 
pretty sure.  But it's Very Hacky :).

>
> The problem is that the stuff that is supposed to find the stack pointer,
> and then use that to find argc, argv, envp, and then auxv_t, so that we can
> locate the elf header...  All that stuff seems utterly broken.  Check it
> out:
>
> 	[andersen at winder uClibc]$ test/args/arg_test a b c d e f
> 	stack=0xbffff770
> 	argc=0x0
> 	argv=Segmentation fault

Ah, hmm.  Yes, I hadn't checked out that angle.  If the stack pointer isn't 
coming in correctly of course everything will be hosed.

> What is especially odd, is that i now use the exact same code for x86 in
> libc/sysdeps/linux/i386/crt0.c.  When I use that crt0.c on ARM (and move
> ldso/d-link/arm out of the way) it also works just fine.  So it works as
> crt0, but not here.  Could the linker be messing up the -e directive? 
> Anyways, I just checked in what I have in the ARM_LDSO_SUPPORT branch in
> CVS, so you can take a look.

Okay, I'll start ripping it apart when my in-laws decide to go home :).  
(I've just snuck into the computer room to check email)

Thanks,
Shane Nay.