From owner-freebsd-hackers Sun Feb 10 23:47: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 9B94737B402 for ; Sun, 10 Feb 2002 23:46:50 -0800 (PST) Received: from pool0243.cvx15-bradley.dialup.earthlink.net ([209.179.44.243] helo=sm.socccd.cc.ca.us) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16aBAi-0004f0-00 for freebsd-hackers@freebsd.org; Sun, 10 Feb 2002 23:46:44 -0800 Message-ID: <3C673A23.DA50C452@yahoo.com> Date: Sun, 10 Feb 2002 19:27:31 -0800 From: Farooq Mela X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Linux binary debugging problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello -hackers, I've got a bit of a problem getting the linux gdb (out of ports/devel/linux_devtools) to read core files generated by linux binaries. Specifically, I'm trying to track down a problem that first appeared in FreeBSD 4.4-RC which causes any of my hardware-accelerated linux binaries to crash immediately upon initializing DRI OpenGL. Anyhow, I've got linux_devtools installed, and I run glxgears, which immediately crashes with "Memory fault (core dumped)" leaving a glxgears.core file. So then I run /compat/linux/usr/bin/gdb /compat/linux/usr/X11R6/bin/glxgears ./glxgears.core which gives me: Couldn't fetch registers from core file: File in wrong format Couldn't fetch register set 2 from core file: File in wrong format Reading symbols from /usr/X11R6/lib/libGL.so.1...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /lib/libpthread.so.0...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /usr/X11R6/lib/modules/dri/mga_dri.so...done. Couldn't fetch registers from core file: File in wrong format Couldn't fetch register set 2 from core file: File in wrong format #0 0x0 in ?? () (gdb) Well, that doesn't help much. It gives me no clue as to where the segfault is taking place. I tried running brandelf -t Linux on the core file and retrying, but to no avail. Could the core file itself be corrupt? This is what file(1) says about it (before i ran brandelf on it): glxgears.core: ELF 32-bit LSB core file (signal 4477762), Intel 80386, version 1 (FreeBSD), from 'glxgears' Strange, shouldn't it report that it's a version 1 (Linux) or something? I was able to get some useful information using ktrace and linux_kdump. Intriguingly, the process first receives a SIGFPE (floating point exception) and then it segfaults immediately afterwards. Could this mean it's trapping SIGFPE and then doing some naughty dereferencing in the FPE signal handler? Output of linux_kdump: ... 35192 glxgears CALL linux_rt_sigaction(0x8,0xbfbff594,0xbfbff508,0x8) 35192 glxgears RET linux_rt_sigaction 0 35192 glxgears PSIG SIGFPE caught handler=0x283ad578 mask=0x80000000 code=0x0 35192 glxgears PSIG SIGSEGV SIG_DFL 35192 glxgears NAMI "glxgears.core" What can the "mask=0x80000000 code=0x0" reveal? I'm assuming it's the floating point status word or some such thing? One last thing, doing a "/compat/linux/usr/bin/gdb /compat/linux/usr/X11R6/bin/glxgears" and then a "run" at the gdb prompt doesn't help either: (gdb) run Starting program: /compat/linux/usr/X11R6/bin/glxgears Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. You can't do that without a process to debug. Hmmm, that's not good. Setting breakpoints doesn't help either. Any tips for debugging linux binaries or getting useful information out of their core files? Any input is appreciated. -- Farooq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message