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

["Ryan S. Arnold" <ryan dot arnold at gmail dot com>]

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.

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
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

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.

Ryan S. Arnold