[uClibc]uClibc ARM shared libs work :)

[Shane Nay]

On Tuesday 19 June 2001 14:47, Philip Blundell wrote:
> >Fixed a problem with argv & argc getting to the application properly, and
> > now busybox works really well with the new ARM shared library system.  I
> > do have
>
> This is all pretty cool stuff.  Can you describe how your implementation of
> shared libraries works?

Yep.  The only major changes I made to what's already inside of of ld-uclibc 
is add all the architecture dependent code for offsetting various types of 
relocations.  (Pieces here borrowed from cross referencing the EABI-ARM doc 
from arm, and glibc-2.2.2)  I had some problems with the stack pointer 
initially, and put it in the assembler code, but I found a work around by 
modding some defines for fetching the argv.  (Still had to leave the 
assembler "pre dl_boot" in otherwise the stackpointer got really messed up)
asm("
_dl_boot: 
	mov r0, sp
	bl _dl_boot_2
	mov r6, r0
	mov r0, sp
	mov pc, r6
")
#define _dl_boot _dl_boot_2

(Of course it uses a semi-sophisticated RTLD thing, I didn't want to impact 
the other architectures so I did this instead)

Then I changed the START() routine that is at the bottom of the c code for 
_dl_boot_2 to instead of "mov pc, "address we figured out"", to return 
"address we figured out", which pipes back to the assembly startup _dl_boot 
routine, and then moves the program counter to the proper place.

I also borrowed Erik's syscall implementation that he wrote while working on 
porting ld-uclibc to ARM because it was cleaner than mine.

Oh..., the one major missing piece is I don't really understand the link 
register.  In my resolver assembler function, I'm supposed to "str" over the 
mem location for something on the stack with the answer the C resolver gave 
me, but I can't really figure out where it is on the stack.  (I'm 
fundamentally an ARM assembler newbie really, I took a crash course by 
reading through the glibc and kernel assembler code, and dissassembling a 
bunch of C code, but my understanding is still pretty immature.)  This only 
affects performance as it will have to re-resolve each run through, so it 
still functions, but for good performance I'll have to fix this.

Basically, I just ported ld.so.1.99 to ARM.  I didn't come up with my own 
shared lib system.  (I did work on a replacement ABI/lib for MIPs a few 
months back with Jay Carlson, but it was very uncomplicated... the 
interprettor was all of 5k)

Thanks,
Shane Nay.