On 24 November 2013 10:51, Waldemar Brodkorb <[email protected]> wrote: > Hi Developers, > > I am trying to find the reason for a SIGBUS error, when
which binutils? ld.gold or bfd? thanks, > using uClibc (git from yesterday) with Qemu 1.6.1 > (qemu-system-mips64). > > My uClibc config is attached. I am cross-compiling from x86_64 > Debian. To successfully startup the Linux system, I use a > eglibc based toolchain and system and then using chroot to trigger > the SIGBUS. Using O32 ABI with uClibc works fine. Using N64 ABI > results in a SIGBUS error, but only when using a binary using shared > libraries. A static binary works fine. > > GDB shows following backtrace: > # gdb /hello > GNU gdb (GDB) 7.6 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "mips64-openadk-linux". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /hello...done. > (gdb) run > Starting program: /hello > _dl_get_ready_to_run:450: Cool, ldso survived making function calls > _dl_malloc:240: mmapping more memory > _dl_ldsopath_init:156: Lib Loader: (0xfffffffff7fe4000) > /lib/ld64-uClibc.so.0: using path: /lib > _dl_get_ready_to_run:661: calling mprotect on the application > program > _dl_load_elf_shared_library:772: Found TLS header for /lib/libc.so.0 > _dl_load_elf_shared_library:799: Relocated TLS initial image from > 0xe7ad0 to 0xfff7fdbad0 (size = 0x8) > _dl_get_ready_to_run:1052: Loading: (0xfff7ef4000) /lib/libc.so.0 > _dl_get_ready_to_run:1052: Loading: (0xfff7fe4000) > /lib/ld64-uClibc.so.0 > _dl_get_ready_to_run:1193: Calling init_tls()! > _dl_malloc:240: mmapping more memory > _dl_get_ready_to_run:1295: Beginning relocation fixups > TLS_TPREL : , 0x8, 0xffffffffffff9000 > TLS_TPREL : , 0xc, 0xffffffffffff9000 > TLS_TPREL : , 0x0, 0xffffffffffff9000 > TLS_TPREL : , 0x10, 0xffffffffffff9000 > TLS_TPREL : __libc_tsd_RPC_VARS, 0x0, 0xffffffffffff9018 > _dl_get_ready_to_run:1325: Calling _dl_allocate_tls_init()! > > Program received signal SIGBUS, Bus error. > 0x000000fff7f63cfc in _stdio_init () at libc/stdio/_stdio.c:257 > 257 libc/stdio/_stdio.c: No such file or directory. > (gdb) bt > #0 0x000000fff7f63cfc in _stdio_init () at libc/stdio/_stdio.c:257 > #1 0x000000fff7fba700 in __uClibc_init () > at libc/misc/internals/__uClibc_main.c:276 > #2 0x000000fff7fec9cc in _dl_get_ready_to_run (tpnt=0xfff7ffd2b0, > load_addr=<optimized out>, auxvt=0xffffffec58, > envp=0xffffffedb8, > argv=<optimized out>) at ldso/ldso/ldso.c:1398 > #3 0x000000fff7fed598 in _dl_start (args=1099511623072) > at ldso/ldso/dl-startup.c:349 > #4 0x000000fff7fe592c in _start () from /lib/ld64-uClibc.so.0 > Backtrace stopped: frame did not save the PC > (gdb) > > It is this line in the code: > int old_errno = errno; > > And after preprocessing: > int old_errno = __libc_errno; > > I have NPTL/TLS enabled in my config. So errno seems to be a per-thread > value. When playing a little bit with gdb, breaking in _stdio_init > I see following: > (gdb) run > Starting program: /hello > _dl_get_ready_to_run:450: Cool, ldso survived making function calls > _dl_malloc:240: mmapping more memory > _dl_ldsopath_init:156: Lib Loader: (0xfffffffff7fe4000) > /lib/ld64-uClibc.so.0: using path: /lib > _dl_get_ready_to_run:661: calling mprotect on the application > program > _dl_load_elf_shared_library:772: Found TLS header for /lib/libc.so.0 > _dl_load_elf_shared_library:799: Relocated TLS initial image from > 0xe7ad0 to 0xfff7fdbad0 (size = 0x8) > _dl_get_ready_to_run:1053: Loading: (0xfff7ef4000) /lib/libc.so.0 > _dl_get_ready_to_run:1053: Loading: (0xfff7fe4000) > /lib/ld64-uClibc.so.0 > _dl_get_ready_to_run:1194: Calling init_tls()! > _dl_malloc:240: mmapping more memory > _dl_get_ready_to_run:1296: Beginning relocation fixups > TLS_TPREL : , 0x8, 0xffffffffffff9000 > TLS_TPREL : , 0xc, 0xffffffffffff9000 > TLS_TPREL : , 0x0, 0xffffffffffff9000 > TLS_TPREL : , 0x10, 0xffffffffffff9000 > TLS_TPREL : __libc_tsd_RPC_VARS, 0x0, 0xffffffffffff9018 > _dl_get_ready_to_run:1326: Calling _dl_allocate_tls_init()! > > Breakpoint 1, _stdio_init () at libc/stdio/_stdio.c:257 > 257 libc/stdio/_stdio.c: No such file or directory. > (gdb) si > 0x000000fff7f63ce0 257 in libc/stdio/_stdio.c > (gdb) disas 0x000000fff7f63ce0,+8 > Dump of assembler code from 0xfff7f63ce0 to 0xfff7f63ce8: > => 0x000000fff7f63ce0 <_stdio_init+36>: move v0,v1 > 0x000000fff7f63ce4 <_stdio_init+40>: ld v1,-26904(gp) > End of assembler dump. > (gdb) p/x $gp-26904 > $1 = 0xfff7fddc58 > (gdb) x/g 0xfff7fddc58 > 0xfff7fddc58: 0xffff900000000008 > (gdb) > > Looks wrong or not? > When I manually fix it, it survives: > > (gdb) set {unsigned long}0xfff7fddc58=0xffffffffffff9000 > (gdb) si > 0x000000fff7f63ce4 257 in libc/stdio/_stdio.c > (gdb) si > 0x000000fff7f63ce8 257 in libc/stdio/_stdio.c > (gdb) si > 0x000000fff7f63cec 257 in libc/stdio/_stdio.c > (gdb) si > 0x000000fff7f63cf0 257 in libc/stdio/_stdio.c > (gdb) si > 259 in libc/stdio/_stdio.c > (gdb) > > So who does set $gp-26904 to the wrong data? > Can anybody help me to fix this? After that there seems a good > chance to unbreak uClibc N64 support. There is another problem, when > using clone systemcall, but I already have a fix for it. > > Thanks for any help, > Waldemar > > > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
