This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] powerpc: 405/440/464/476 support and optimizations
On Mon, 23 Jan 2012 09:48:19 -0600
"Ryan S. Arnold" <ryan.arnold@gmail.com> wrote:
> On Sun, Jan 22, 2012 at 6:42 PM, acrux <acrux_it@libero.it> wrote:
> >> If that works then I suspect that the problem is related to the string
> >> routine optimizations that one of my guys put in for the 476
> >> processor. ?It was requested that we provide it to the entire 4xx
> >> series since the instructions used (allegedly) weren't unique to the
> >> 476.
> >>
> >> It'd be interesting to run a debugger against the loader at this point
> >> and identify whether you're encountering a sigill or a sigsegv.
> >>
> >
> > btw, i guess a SIGSEGV because it simply stuck there and cpu goes idle.
> > If you need i can provide to you an ssh access on this little board [3].
>
> Hi Nico, I think you should debug the loader and get a backtrace.
> You'll use the instructions here:
>
> http://sourceware.org/glibc/wiki/Debugging/Loader_Debugging#Debugging_With_An_Alternate_Loader
>
> I've made it easy for you. Here's two scripts with your build
> directory already embedded. What you need to do is invoke GDB using
> the new loader if you can (so that you don't get library mismatching)
> and then tell GDB (with the .gdb script) to debug the loader.
>
> Here's the .gdb script you'll use:
>
> rpcgen.gdb:
> ------------------------------------
> set environment gcc -m32 C -E -x c-header
> break _dl_main_dispatch
> run --library-path
> /home/999/new/work/src/build32/:\
> /home/999/new/work/src/build32/nptl:\
> /home/999/new/work/src/build32/math:\
> /home/999/new/work/src/build32/elf:\
> /home/999/new/work/src/build32/dlfcn:\
> /home/999/new/work/src/build32/nss:\
> /home/999/new/work/src/build32/nis:\
> /home/999/new/work/src/build32/rt:\
> /home/999/new/work/src/build32/resolv:\
> /home/999/new/work/src/build32/crypt:\
> /home/999/new/work/src/build32/nptl:\
> /home/999/new/work/src/build32/nptl_db \
> /home/999/new/work/src/build32/sunrpc/rpcgen -Y
> /home/999/new/work/src/scripts -c
> /home/999/new/work/src/build32/sunrpc/rpcsvc/bootparam_prot.x -o
> /home/999/new/work/src/build32/sunrpc/xbootparam_prot.T
>
>
> Here's the shell script which will invoke GDB:
>
> debug_rpcgen.sh:
> -------------------------------------
> #!/bin/bash
>
> ulimit -c unlimited
> GLIBC="/home/999/new/work/src/build32/"
>
> CPP='gcc -m32 -E -x c-header' \
> ${GLIBC}/elf/ld.so.1 --library-path \
> ${GLIBC}:\
> ${GLIBC}/math:\
> ${GLIBC}/elf:\
> ${GLIBC}/dlfcn:\
> ${GLIBC}/nss:\
> ${GLIBC}/nis:\
> ${GLIBC}/rt:\
> ${GLIBC}/resolv:\
> ${GLIBC}/crypt:\
> ${GLIBC}/nptl:\
> ${GLIBC}/nptl_db: \
> /usr/bin/gdb -x rpcgen.gdb -d home/999/new/work/src/build32/elf/ld.so.1
>
> So try running debug_rpcgen.sh first.
>
hi Ryan,
thanks. I just did some minor fix to your scripts to have the correct path for my built
# cat > rpcgen.gdb << "EOF"
set environment gcc -m32 C -E -x c-header
break _dl_main_dispatch
run --library-path \
/home/999/new/work/src/build32/:\
/home/999/new/work/src/build32/nptl:\
/home/999/new/work/src/build32/math:\
/home/999/new/work/src/build32/elf:\
/home/999/new/work/src/build32/dlfcn:\
/home/999/new/work/src/build32/nss:\
/home/999/new/work/src/build32/nis:\
/home/999/new/work/src/build32/rt:\
/home/999/new/work/src/build32/resolv:\
/home/999/new/work/src/build32/crypt:\
/home/999/new/work/src/build32/nptl:\
/home/999/new/work/src/build32/nptl_db \
/home/999/new/work/src/build32/sunrpc/rpcgen -Y \
/home/999/new/work/src/glibc-2.13/scripts -c \
/home/999/new/work/src/glibc-2.13/sunrpc/rpcsvc/bootparam_prot.x -o \
/home/999/new/work/src/build32/sunrpc/xbootparam_prot.T
EOF
# cat > debug_rpcgen.sh << "EOF"
#!/bin/bash
ulimit -c unlimited
GLIBC="/home/999/new/work/src/build32/"
CPP='gcc -m32 -E -x c-header' \
${GLIBC}/elf/ld.so.1 --library-path \
${GLIBC}:\
${GLIBC}/math:\
${GLIBC}/elf:\
${GLIBC}/dlfcn:\
${GLIBC}/nss:\
${GLIBC}/nis:\
${GLIBC}/rt:\
${GLIBC}/resolv:\
${GLIBC}/crypt:\
${GLIBC}/nptl:\
${GLIBC}/nptl_db \
/usr/bin/gdb -x rpcgen.gdb /home/999/new/work/src/build32/elf/ld.so.1
EOF
> If it works the loader should be breaking in the loader on
> _dl_main_dispatch. You can simply (gdb) continue at this point and
> the loader should crash whereby gdb will trap and show you where it
> crashed and why (segfault or sigill).
>
> If debug_rpcgen.sh crashes immediately without GDB coming up it means
> that the loader itself is crashing in the string routines (which is
it's right, it simply stuck.
> the most likely scenario). If that is the case you should try running
> the debugger with the system loader instead. You may get some library
> mismatch warnings but do the following:
>
> CPP='gcc -m32 -E -x -c-header' /usr/bin/gdb -x rpcgen.gdb -d
> home/999/new/work/src/build32/elf/ld.so.1
>
# CPP='gcc -m32 -E -x -c-header' /usr/bin/gdb -x rpcgen.gdb /home/999/new/work/src/build32/elf/ld.so.1
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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 "powerpc-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/999/new/work/src/build32/elf/ld.so.1...(no debugging symbols found)...done.
Breakpoint 1 at 0x163c0
Breakpoint 1, 0x204b73c0 in _dl_main_dispatch () from /home/999/new/work/src/build32/elf/ld.so.1
(gdb) info proc mapping
process 2575
cmdline = '/home/999/new/work/src/build32/elf/ld.so.1'
cwd = '/home/999/ryan'
exe = '/home/999/new/work/src/build32/elf/ld.so'
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x100000 0x102000 0x2000 0 [vdso]
0xfe82000 0xffd8000 0x156000 0 /home/999/new/work/src/build32/libc.so
0xffd8000 0xffe8000 0x10000 0x156000 /home/999/new/work/src/build32/libc.so
0xffe8000 0xffea000 0x2000 0x156000 /home/999/new/work/src/build32/libc.so
0xffea000 0xffed000 0x3000 0x158000 /home/999/new/work/src/build32/libc.so
0xffed000 0xfff0000 0x3000 0
0x10000000 0x10014000 0x14000 0 /home/999/new/work/src/build32/sunrpc/rpcgen
0x10023000 0x10024000 0x1000 0x13000 /home/999/new/work/src/build32/sunrpc/rpcgen
0x10024000 0x10025000 0x1000 0x14000 /home/999/new/work/src/build32/sunrpc/rpcgen
0x204a1000 0x204bf000 0x1e000 0 /home/999/new/work/src/build32/elf/ld.so
0x204ce000 0x204cf000 0x1000 0x1d000 /home/999/new/work/src/build32/elf/ld.so
0x204cf000 0x204d1000 0x2000 0x1e000 /home/999/new/work/src/build32/elf/ld.so
0x48000000 0x48002000 0x2000 0
0xbffdf000 0xc0000000 0x21000 0 [stack]
(gdb) bt
#0 0x204b73c0 in _dl_main_dispatch () from /home/999/new/work/src/build32/elf/ld.so.1
#1 0x00000000 in ?? ()
(gdb) continue
Continuing.
well... now it stuck... and i must do a ctrl-c
^C
Program received signal SIGINT, Interrupt.
0x0ff70c80 in __lll_lock_wait_private () from /home/999/new/work/src/build32/libc.so.6
(gdb) bt
#0 0x0ff70c80 in __lll_lock_wait_private () from /home/999/new/work/src/build32/libc.so.6
#1 0x0febb2e4 in __new_exitfn () from /home/999/new/work/src/build32/libc.so.6
#2 0x0febb338 in __internal_atexit () from /home/999/new/work/src/build32/libc.so.6
#3 0x0fea174c in generic_start_main.clone.0 () from /home/999/new/work/src/build32/libc.so.6
#4 0x0fea1970 in __libc_start_main () from /home/999/new/work/src/build32/libc.so.6
#5 0x00000000 in ?? ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 2575] will be killed.
Quit anyway? (y or n) y
> If it successfully traps in _dl_main_dispatch do what I mentioned
> above to see where the loader is crashing.
>
> Let me know where/why it is crashing.
>
that's all folks!
best,
--nico
--
acrux <acrux@cruxppc.org>