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@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 r...@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, _...@0xe59fa03c, _...@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, _...@0xe59fa03c, _...@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. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community