Re: [PATCH] powerpc: 405/440/464/476 support and optimizations

[acrux <acrux_it@libero.it>]

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>