|
uClibc supporting shared libs on mipsel: msg#00102lib.uclibc.general
Hi folks I'm trying to get a shared lib uClibc running on a Helio pda. Its got a Toshiba TMPR3912AU, 75 MHz., 32-bit RISC processor running mipsel-linux (kernel 2.4.0-test1-ac22). I'm using uClibc v0.9.18 I've got a glibc based distro running busybox on the thing. I want to use uClibc for the space savings. ldso/ldso/ldso.c grabs some kind of header from the Auxiliary Vector Table header = (elfhdr *) auxvt[AT_BASE].a_un.a_ptr; My uClibc crashes because header contains 0x0. The docs in ldso.c said to look at fs/binfmt_elf.c where it makes a bunch of calls to NEW_AUX_ENT. I added code to print out what NEW_AUX_ENT is sticking on the stack. It gave me: NEW_AUX_ENT nr=0 d=0 val=0 store id at addr=fffffb8 (the leading 7 is cut off) store val at addr7fffffbc NEW_AUX_ENT nr=0 d=10 val=0 store id at addr=fffffb0 store val at addr7fffffb4 NEW_AUX_ENT nr=0 d=3 val=400034 store id at addr=fffff58 store val at addr7fffff5c NEW_AUX_ENT nr=1 d=4 val=20 store id at addr=fffff60 store val at addr7fffff64 NEW_AUX_ENT nr=2 d=5 val=6 store id at addr=fffff68 store val at addr7fffff6c NEW_AUX_ENT nr=3 d=6 val=1000 store id at addr=fffff70 store val at addr7fffff74 NEW_AUX_ENT nr=4 d=7 val=0 store id at addr=fffff78 store val at addr7fffff7c NEW_AUX_ENT nr=5 d=8 val=0 store id at addr=fffff80 store val at addr7fffff84 NEW_AUX_ENT nr=6 d=9 val=402ec0 store id at addr=fffff88 store val at addr7fffff8c NEW_AUX_ENT nr=7 d=b val=0 store id at addr=fffff90 store val at addr7fffff94 NEW_AUX_ENT nr=8 d=c val=0 store id at addr=fffff98 store val at addr7fffff9c NEW_AUX_ENT nr=9 d=d val=0 store id at addr=fffffa0 store val at addr7fffffa4 NEW_AUX_ENT nr=a d=e val=0 store id at addr=fffffa8 store val at addr7fffffac I threw code into ldso.c to print out the values it reads from the Auxiliary Vector Table (its below and everything is the same). I also had it dump the address of where it was getting the value for header out of auxvt. It tells me: getting header from auxvt entry at address 0x7ffffcf0 This entry is loaded with: loop filling auxvt with data at 0x7fffff78 address of auxvt getting the data is 0x7ffffcf0 auxv_entry a_type=00000007 a_un.a_val=00000000 a_un.a_ptr=00000000 a_un.a_fcn=00000000 This matches what the kernel says it placed in this address. So I know memory didn't get whacked. What does uClibc want to be there? Am I completely out of luck for running shared libs and uClibc? BTW, I got a dump of the Aux Vec Tbl from kernel in the glibc based distro. Everything matched except for 1 entry. But it wasn't the one uClibc is using as header. That entry was the same as shown above. I've been chasing this around for about a month and I'm running out of ideas. Any help, ideas or suggestions would be greatly appreciated. Mark Here's the contents of the Auxiliary Vector Table as found by uClibc's ldso.c: loop filling auxvt with data at 0x7fffff58 address of auxvt getting the data is 0x7ffffcd0 auxv_entry a_type=00000003 a_un.a_val=00400034 a_un.a_ptr=00400034 a_un.a_fcn=00400034 loop filling auxvt with data at 0x7fffff60 address of auxvt getting the data is 0x7ffffcd8 auxv_entry a_type=00000004 a_un.a_val=00000020 a_un.a_ptr=00000020 a_un.a_fcn=00000020 loop filling auxvt with data at 0x7fffff68 address of auxvt getting the data is 0x7ffffce0 auxv_entry a_type=00000005 a_un.a_val=00000006 a_un.a_ptr=00000006 a_un.a_fcn=00000006 loop filling auxvt with data at 0x7fffff70 address of auxvt getting the data is 0x7ffffce8 auxv_entry a_type=00000006 a_un.a_val=00001000 a_un.a_ptr=00001000 a_un.a_fcn=00001000 loop filling auxvt with data at 0x7fffff78 address of auxvt getting the data is 0x7ffffcf0 auxv_entry a_type=00000007 a_un.a_val=00000000 a_un.a_ptr=00000000 a_un.a_fcn=00000000 loop filling auxvt with data at 0x7fffff80 address of auxvt getting the data is 0x7ffffcf8 auxv_entry a_type=00000008 a_un.a_val=00000000 a_un.a_ptr=00000000 a_un.a_fcn=00000000 loop filling auxvt with data at 0x7fffff88 address of auxvt getting the data is 0x7ffffd00 auxv_entry a_type=00000009 a_un.a_val=00402ec0 a_un.a_ptr=00402ec0 a_un.a_fcn=00402ec0 loop filling auxvt with data at 0x7fffff90 address of auxvt getting the data is 0x7ffffd10 auxv_entry a_type=0000000b a_un.a_val=00000000 a_un.a_ptr=00000000 a_un.a_fcn=00000000 loop filling auxvt with data at 0x7fffff98 address of auxvt getting the data is 0x7ffffd18 auxv_entry a_type=0000000c a_un.a_val=00000000 a_un.a_ptr=00000000 a_un.a_fcn=00000000 loop filling auxvt with data at 0x7fffffa0 address of auxvt getting the data is 0x7ffffd20 auxv_entry a_type=0000000d a_un.a_val=00000000 a_un.a_ptr=00000000 a_un.a_fcn=00000000 loop filling auxvt with data at 0x7fffffa8 address of auxvt getting the data is 0x7ffffd28 auxv_entry a_type=0000000e a_un.a_val=00000000 a_un.a_ptr=00000000 a_un.a_fcn=00000000 _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: Quest for missing symbols: __gxx_personality_v0 solved, __fixdfsi not: 00102, Erik Andersen |
|---|---|
| Next by Date: | Error in newly checked in file: 00102, Svein-Erik Skjelbred |
| Previous by Thread: | Quest for missing symbols: __gxx_personality_v0 solved, __fixdfsi noti: 00102, David Wuertele |
| Next by Thread: | Re: uClibc supporting shared libs on mipsel: 00102, Erik Andersen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |