From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15826 invoked by alias); 23 Jan 2012 15:48:37 -0000 Received: (qmail 15815 invoked by uid 22791); 23 Jan 2012 15:48:35 -0000 X-SWARE-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bk0-f41.google.com (HELO mail-bk0-f41.google.com) (209.85.214.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jan 2012 15:48:21 +0000 Received: by bkbzx1 with SMTP id zx1so2777205bkb.0 for ; Mon, 23 Jan 2012 07:48:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.152.26 with SMTP id e26mr3345874bkw.87.1327333700103; Mon, 23 Jan 2012 07:48:20 -0800 (PST) Received: by 10.204.59.135 with HTTP; Mon, 23 Jan 2012 07:48:19 -0800 (PST) In-Reply-To: <20120123014224.77d3c1fa.acrux_it@libero.it> References: <1283448864.3854.56.camel@gargoyle> <1283526020.3854.77.camel@gargoyle> <1286218436.3679.1.camel@gargoyle> <1292271927.3622.6.camel@localhost.localdomain> <33163939.post@talk.nabble.com> <20120120152428.df02fbc4.acrux_it@libero.it> <20120123014224.77d3c1fa.acrux_it@libero.it> Date: Mon, 23 Jan 2012 15:48:00 -0000 Message-ID: Subject: Re: [PATCH] powerpc: 405/440/464/476 support and optimizations From: "Ryan S. Arnold" To: acrux Cc: "Carlos O'Donell" , libc-ports@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00042.txt.bz2 On Sun, Jan 22, 2012 at 6:42 PM, acrux 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. =C2=A0It 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=3D"/home/999/new/work/src/build32/" CPP=3D'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=3D'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