Installing and using a recent gdb 6.6 on a N800 device

This GDB crashes less. It also gives you far more debugging information, from the stack, than the GDB 6.4 default package on the Nokia images. Nuff said.

Compiling your own

In scratchbox it's pretty much a standard configure make make install procedure on the tarball release.

• http://sourceware.org/gdb/download/

cd gdb-6.6
./configure --prefix=/opt
make && make install

Downloading a pre-compiled binary

For the N800, ARM

• http://pvanhoof.be/files/gdb-arm-n800-6.6.tar.gz

For Scratchbox, intel rootstrap

• http://pvanhoof.be/files/gdb-6.6-sb-intel.tar.gz

Installing it

cd /opt
tar zxvf gdb-arm-n800-6.6.tar.gz
cd gdb/lib
## This makes gdb find debugging symbols of -dbg packages
ln -s /usr/lib/debug .
su - user
unset AF_DEFINES_SOURCED
source /etc/osso-af-init/af-defines.sh
echo "handle SIG33 noprint nostop" > ~/.gdbinit
echo "handle SIG32 noprint nostop" >> ~/.gdbinit
export PATH=/opt/gdb/bin:$PATH
gdb modest `pidof modest`
(gdb) break camel-local-store.c:382
Breakpoint 3 at 0x41503a84: file camel-local-store.c, line 382.
(gdb) cont

Summary

In your N800's user's $HOME:

~ $ cat .profile 
unset AF_DEFINES_SOURCED
source /etc/osso-af-init/af-defines.sh
export PATH=/opt/gdb/bin:$PATH
~ $ cat .gdbinit 
handle SIG33 noprint nostop
handle SIG32 noprint nostop
~ $ 

This GDB should also work at startup

I noticed that ptrace sometimes hangs while connecting. I think this is a fork() call that doesn't do an execv and lets the parent dry out, hoping the child with pickup. As far as I know should ptrace cope with fork(), though. I also sometimes succeeded with getting it to work. Maybe a compilation switch to turn-off conic? I think it's because of conic that gdb can't cope with the initialization of Modest.

export PATH=/opt/gdb/bin:$PATH
gdb modest
(gdb) set args showui
(gdb) run

Some extra options that you can try

On ARM the kernel seems to be using processes for threads (like the good old days of the 2.2 kernel, I guess). While using gdb on ARM targets I noticed that ptrace often loses the process. Therefore you can try experimenting a bit with the options "detach-on-fork" and "follow-fork-mode":

~ $ cat .gdbinit 
handle SIG33 noprint nostop
handle SIG32 noprint nostop
set detach-on-fork off
set follow-fork-mode child
show detach-on-fork
show follow-fork-mode
~ $