Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Feb 2002 19:27:31 -0800
From:      Farooq Mela <f_mela@yahoo.com>
To:        freebsd-hackers@freebsd.org
Subject:   Linux binary debugging problem
Message-ID:  <3C673A23.DA50C452@yahoo.com>

next in thread | raw e-mail | index | archive | help
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:

<snip some irrevelant output>
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 <fmela0@sm.socccd.cc.ca.us>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C673A23.DA50C452>