[uClibc]Shared libs, ARM

[Erik Andersen]

On Sat Jun 16, 2001 at 01:29:18AM -0700, Shane Nay wrote:
> Okay, the ld-uclibc stuff wasn't in CVS for ARM.  So I've been tinkering with 
> it on the skiff clusters (you can look at where I'm at on any of them at 

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...

> /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.  

What we _can_ do is create strings on the fly and use them, i.e:

	char char[30;
	...
        crap[0] = 's';
        crap[1] = 't';
        crap[2] = 'a';
        crap[3] = 'c';
        crap[4] = 'k';
        crap[5] = '=';
        crap[6] = '\0';
        SEND_STDERR(crap);
        SEND_NUMBER_STDERR(stack, 1);

        crap[0] = 'a';
        crap[1] = 'r';
        crap[2] = 'g';
        crap[3] = 'c';
        crap[4] = '=';
        crap[5] = '\0';
        SEND_STDERR(crap);
        SEND_NUMBER_STDERR(argc, 1);

        crap[0] = 'a';
        crap[1] = 'r';
        crap[2] = 'g';
        crap[3] = 'v';
        crap[4] = '=';
        crap[5] = '\0';
        SEND_STDERR(crap);
        SEND_STDERR(argv[0]);

        crap[0] = '\n';
        crap[1] = '\0';
        SEND_STDERR(crap);


        crap[0] = 'e';
        crap[1] = 'n';
        crap[2] = 'v';
        crap[3] = 'p';
        crap[4] = '=';
        crap[5] = '\0';
        SEND_STDERR(crap);
        SEND_STDERR(envp[0]);
        crap[0] = '\n';
        crap[1] = '\0';
        SEND_STDERR(crap);


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

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.

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--