So, it appears elf_machine_relative() was never implemented for MIPS.
Thats why the debug strings _dl_reltypes_tab are not fixed up.
Is anyone else trying to use uClibc with MIPS ?
Colin..
Colin Whittaker wrote:
The debug segfault occurs when the "reloc" flag is set.
Looks like the _dl_reltypes_tab symbol is not fixed up correctly in ldso.
I don't really understand this.
gdb shows _dl_reltypes_tab as 0x9af0, which happens to be the offset
in the file.
But I couldn't find the symbol with objdump.
How do I find the symbols that need to be fixed up with objdump ?
Colin..
Colin Whittaker wrote:
I turned on SUPPORT_LD_DEBUG=y
Now with LD_DEBUG=all, it segfaults everytime.
Without the LD_DEBUG=all, it runs without segfault, except the very
first time...
At least I have consistent behavior now.
Here is the output of
# LD_DEBUG=all scp
_dl_get_ready_to_run:587: file='libutil.so.0'; needed by 'scp'
_dl_load_shared_library:222: find library='libutil.so.0'; searching
_dl_load_shared_library:298: searching ldso dir='/lib'
_dl_load_elf_shared_library:639:
file='/lib/libutil.so.0'; generating link map
_dl_load_elf_shared_library:640: dynamic: 0x2aac412c
base: 0x2aac4000
_dl_load_elf_shared_library:642: entry: 0x2aac4730
phdr: 0x2aac4034 phnum: 0x7
_dl_get_ready_to_run:587: file='libz.so.1'; needed by 'scp'
_dl_load_shared_library:222: find library='libz.so.1'; searching
_dl_load_shared_library:298: searching ldso dir='/lib'
_dl_load_shared_library:307: searching full lib path list
_dl_load_elf_shared_library:639:
file='/usr/lib/libz.so.1'; generating link map
_dl_load_elf_shared_library:640: dynamic: 0x2aad610c
base: 0x2aad6000
_dl_load_elf_shared_library:642: entry: 0x2aad7200
phdr: 0x2aad6034 phnum: 0x6
_dl_get_ready_to_run:587: file='libcrypt.so.0'; needed by 'scp'
_dl_load_shared_library:222: find library='libcrypt.so.0'; searching
_dl_load_shared_library:298: searching ldso dir='/lib'
_dl_load_elf_shared_library:639:
file='/lib/libcrypt.so.0'; generating link map
_dl_load_elf_shared_library:640: dynamic: 0x2aaf812c
base: 0x2aaf8000
_dl_load_elf_shared_library:642: entry: 0x2aaf84c0
phdr: 0x2aaf8034 phnum: 0x7
_dl_get_ready_to_run:587: file='libc.so.0'; needed by 'scp'
_dl_load_shared_library:222: find library='libc.so.0'; searching
_dl_load_shared_library:298: searching ldso dir='/lib'
_dl_load_elf_shared_library:639:
file='/lib/libc.so.0'; generating link map
_dl_load_elf_shared_library:640: dynamic: 0x2ab1e14c
base: 0x2ab1e000
_dl_load_elf_shared_library:642: entry: 0x2ab28af0
phdr: 0x2ab1e034 phnum: 0x8
_dl_get_ready_to_run:587: file='libc.so.0'; needed by 'scp'
_dl_load_shared_library:222: find library='libc.so.0'; searching
_dl_load_shared_library:298: searching ldso dir='/lib'
_dl_get_ready_to_run:587: file='libc.so.0'; needed by 'scp'
_dl_load_shared_library:222: find library='libc.so.0'; searching
_dl_load_shared_library:298: searching ldso dir='/lib'
_dl_get_ready_to_run:587: file='libc.so.0'; needed by 'scp'
_dl_load_shared_library:222: find library='libc.so.0'; searching
_dl_load_shared_library:298: searching ldso dir='/lib'
INIT/FINI order and dependencies:
lib: /lib/libutil.so.0 has deps:
/lib/libc.so.0
lib: /usr/lib/libz.so.1 has deps:
/lib/libc.so.0
lib: /lib/libcrypt.so.0 has deps:
/lib/libc.so.0
lib: /lib/libc.so.0 has deps:
_dl_perform_mips_global_got_relocations for 'scp'
_dl_perform_mips_global_got_relocations for '/lib/libutil.so.0'
_dl_perform_mips_global_got_relocations for '/usr/lib/libz.so.1'
_dl_perform_mips_global_got_relocations for '/lib/libcrypt.so.0'
_dl_perform_mips_global_got_relocations for '/lib/libc.so.0'
_dl_fixup:664: relocation processing: /lib/libc.so.0
Segmentation fault
# scp
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
[-l limit] [-o ssh_option] [-P port] [-S program]
[[u...@]host1:]file1 [...] [[u...@]host2:]file2
#
Colin Whittaker wrote:
I am seeing what Nigel saw in the thread of the same name.
I am running on mips.
Basically after the ldso loads everything it goes and tries to run
the init function with DL_CALL_FUNC_AT_ADDR().
First time it runs __GI___uClibc_init which is in libc.so.0
Second time it points to something called _init which appears to be
in the .init section of libz.so.1
It crashes in there. From what I see it looks like a bad address in
the GOT.
If I run the same program again. It does not crash. And everytime
after that it does not crash.
Weird....
Then another application, which uses other libs, has the same
problem. 1st time it crashes during init. 2nd time and ever after it
runs fine.
I never did see if Nigel found a fix. I am using the
LINUXTHREADS_OLD=y
PTHREADS_DEBUG_SUPPORT=y
I've tried both 0.29 and 0.30.
Any thoughts ?
Colin..
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
