OpenMoko, glibc and backtrace

[GNUtoo]

On Tue, 2009-05-05 at 19:19 +0200, Mile Davidovic wrote:
> Hello
> I tried to use backtrace function from glibc on OM and I failed.
> 
> I tried some google and I found some page which claims that backtrace
> is not supported in arm eabi.
> Also, I tried to debug some application with gdbserver and it seems
> that bt command does not work as expected.
> 
> Do we have some wiki page about debugging OM?
> 
> Kind regards
> Mile
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

hi,I tried debuging wesnoth on the openmoko and succeeded.
however I was told to use svn boost wich didn't compile,I must look into
it.
I wrote how I've done it here:
http://gnutoo.homelinux.org/blog/index.php?entry=entry090410-230918

I'll paste the content here for convenience:

debugging wesnoth on the openmoko(128MB of ram) 
Friday, April 10, 2009, 11:09 PM - openembedded
Posted by Administrator
I've successfully produced a stacktrace from wesnoth under gdb on the
openmoko.
Here's are the problem:
*gdb didn't work on the openmoko...it was related to this bugreport:
http://sourceware.org/bugzilla/show_bug.cgi?id=10046 I or someone must
fix it.
*gdbserver->gdb did work under the openmoko...but it went out of ram
while loading the symbols...
There are several remainings solutions:
*make it produce a coredump and load it under your desktop/laptop
computer
*use gdbserver(openmoko,armv4t,128MB of ram)->gdb(x86,lot of ram)
*use another solution like qemu but 
**qemu from openmoko had problems:
***uboot didn't load the kenrel and rebooted the (virtual) machine
***qemu refused to load something else than a (virtual) flash disk
**use normal qemu-system-arm with another (virtual) machine:
***or must cross-compile a system from scratch for it(using openembedded
of course)
***or must use an existing system and so you need to do some hard work
to make your application on it
*use swap(slow and would need repartitioningworks only if you have
enough space

so here's the solution for the core:
*check if the core dump size is illimited:
# ulimit
unlimited
else set it to unlimited:
# ulimit unlimited
*then create a directory and cd into it
$ mkdir cr
$ cd cr
*then make the application produce the core file:
$ export DISPLAY=:0
$ wesnoth -f -r 480x640 --log-debug=all
*then export your device's filesystem trough ssh
# sshfs root at 192.168.0.202:/ /mnt/moko/
*then compile gdb for armv target:
**or use openembedded: 
$ bitbake gdb-cross
$ ~/oetmp/cross/armv4t/bin/arm-angstrom-linux-gnueabi-gdb
replace ~/oetmp by your openembedded temp dir
**if you don't have openembedded use this commands:
$ wget http://ftp.gnu.org/gnu/gdb/gdb-6.8.tar.bz2
$ tar xvzf gdb-6.8.tar.bz2
$ cd gdb-6.8
$ ./configure --target=arm-linux
$ make
$ cd gdb
$ cp gdb ../../
$ cd ../../
$ gdb

then you are into gdb:
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-linux".
(gdb) set sysroot /mnt/moko
(gdb) file /mnt/moko/usr/bin/wesnoth
Reading symbols from /mnt/moko/usr/bin/wesnoth...Reading symbols
from /mnt/moko/usr/bin/.debug/wesnoth...done.
done.
(gdb) target core core
Loaded symbols for /mnt/moko/usr/lib/libSDL-1.2.so.0
Loaded symbols for /mnt/moko/lib/libpthread.so.0
Loaded symbols for /mnt/moko/usr/lib/libboost_iostreams-mt-d.so
Loaded symbols for /mnt/moko/usr/lib/libboost_regex-mt-d.so
Loaded symbols for /mnt/moko/usr/lib/libSDL_image-1.2.so.0
Loaded symbols for /mnt/moko/usr/lib/libSDL_mixer-1.2.so.0
Loaded symbols for /mnt/moko/usr/lib/libSDL_net-1.2.so.0
Loaded symbols for /mnt/moko/usr/lib/libSDL_ttf-2.0.so.0
Loaded symbols for /mnt/moko/usr/lib/libpangocairo-1.0.so.0
Loaded symbols for /mnt/moko/usr/lib/libpango-1.0.so.0
Loaded symbols for /mnt/moko/usr/lib/libcairo.so.2
Loaded symbols for /mnt/moko/usr/lib/libgobject-2.0.so.0
Loaded symbols for /mnt/moko/usr/lib/libgmodule-2.0.so.0
Loaded symbols for /mnt/moko/lib/libdl.so.2
Loaded symbols for /mnt/moko/usr/lib/libglib-2.0.so.0
Loaded symbols for /mnt/moko/usr/lib/libfontconfig.so.1
Loaded symbols for /mnt/moko/usr/lib/libX11.so.6
Loaded symbols for /mnt/moko/usr/lib/libXext.so.6
Loaded symbols for /mnt/moko/usr/lib/libstdc++.so.6
Loaded symbols for /mnt/moko/lib/libm.so.6
Loaded symbols for /mnt/moko/lib/libgcc_s.so.1
Loaded symbols for /mnt/moko/lib/libc.so.6
Loaded symbols for /mnt/moko/usr/lib/libts-1.0.so.0
Loaded symbols for /mnt/moko/lib/ld-linux.so.3
Loaded symbols for /mnt/moko/usr/lib/libz.so.1
Loaded symbols for /mnt/moko/lib/librt.so.1
Loaded symbols for /mnt/moko/usr/lib/libfreetype.so.6
Loaded symbols for /mnt/moko/usr/lib/libpangoft2-1.0.so.0
Loaded symbols for /mnt/moko/usr/lib/libpng12.so.0
Loaded symbols for /mnt/moko/usr/lib/libXrender.so.1
Loaded symbols for /mnt/moko/usr/lib/libpixman-1.so.0
Loaded symbols for /mnt/moko/usr/lib/libexpat.so.1
Loaded symbols for /mnt/moko/usr/lib/libXau.so.6
Loaded symbols for /mnt/moko/usr/lib/libXdmcp.so.6
Reading symbols from /mnt/moko/usr/lib/libXcursor.so.1...done.
Loaded symbols for /mnt/moko/usr/lib/libXcursor.so.1
Reading symbols from /mnt/moko/usr/lib/libXfixes.so.3...done.
Loaded symbols for /mnt/moko/usr/lib/libXfixes.so.3
Reading symbols from /mnt/moko/usr/lib/gconv/ISO8859-1.so...done.
Loaded symbols for /mnt/moko/usr/lib/gconv/ISO8859-1.so
Reading symbols from /mnt/moko/lib/libnss_files.so.2...done.
Loaded symbols for /mnt/moko/lib/libnss_files.so.2
Reading symbols from /mnt/moko/lib/libnss_dns.so.2...done.
Loaded symbols for /mnt/moko/lib/libnss_dns.so.2
Reading symbols from /mnt/moko/lib/libresolv.so.2...done.
Loaded symbols for /mnt/moko/lib/libresolv.so.2
Core was generated by `wesnoth -f -r 480x640 --log-debug=all'.
Program terminated with signal 11, Segmentation fault.
[New process 1724]
#0 0x00215c90 in std::less<int>::operator() (this=0xcf4748,
__x=@0xe59fa03c, __y=@0xbec5fddc)
at /home/embedded/oetmp_openmoko/staging/armv4t-angstrom-linux-gnueabi//usr/include/c++/bits/stl_function.h:227
227 { return __x < __y; }
then you only have to do a backtrace using bt
note that I copied the core on the local filesystem here...

update:
here's the remote debugging session:
# ./arm-angstrom-linux-gnueabi-gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-linux
--target=arm-angstrom-linux-gnueabi".
(gdb) set sysroot /mnt/moko
(gdb) file /mnt/moko/usr/bin/wesnoth
Reading symbols from /mnt/moko/usr/bin/wesnoth...Reading symbols
from /mnt/moko/usr/bin/.debug/wesnoth...done.
done.
(gdb) target remote 192.168.0.202:8022
Remote debugging using 192.168.0.202:8022
[New Thread 3010]
0x400007f0 in ?? () from /mnt/moko/lib/ld-linux.so.3
(gdb) c
Continuing.
[New Thread 3110]
[New Thread 3111]

Program received signal SIGSEGV, Segmentation fault.
0x00215c98 in std::less<int>::operator() (this=0xcf4748,
__x=@0xe59fa03c, __y=@0xbede1dfc)
at /home/embedded/oetmp_openmoko/staging/armv4t-angstrom-linux-gnueabi//usr/include/c++/bits/stl_function.h:227
227 { return __x < __y; }

gdbserver was started on the openmoko with:
# export DISPLAY=:0
# gdbserver 192.168.0.202:8022 wesnoth -r 480x640 -f

Denis.

PS: I license the content of the post and of this mail under the MIT
license so you can (and are encouraged to) use it in order to make a
howto.
If I remember well MIT license doesn't require attribution.