Hi all,
I am currently working with some c++ code on an ARM processor. The issue i am having is that when my application hits a segfault i am unable to get any information as to what caused it.
My dev machine is ubuntu 10.04 LTS and i am using eclipse as my IDE (just for how it looks, the compliation is a makefile using autoconf). Im using the GCC ARM cross compiler from openembedded and the cross compiled GDB also from openembedded. Output of compiler version below.
arm-angstrom-linux-gnueabi-g++ -v
Using built-in specs.
Target: arm-angstrom-linux-gnueabi
Configured with: /home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-cross-4.3.3-r23.2/gcc-4.3.3/configure --build=i686-linux --host=i686-linux --target=arm-angstrom-linux-gnueabi --prefix=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a --exec_prefix=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a --bindir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/bin --sbindir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/bin --libexecdir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/libexec --datadir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/share --sysconfdir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/etc --sharedstatedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/com --localstatedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/var --libdir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/lib --includedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/include --oldincludedir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/include --infodir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/share/info --mandir=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/share/man --enable-largefile --disable-nls --enable-ipv6 --with-gnu-ld --enable-shared --enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace --enable-cheaders=c_std --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-sysroot=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi --with-build-sysroot=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi --with-build-time-tools=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr/armv7a/bin --enable-cheaders=c_std --disable-libunwind-exceptions --with-mpfr=/home/robert/openembedded/angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/i686-linux/usr --program-prefix=arm-angstrom-linux-gnueabi- --enable-__cxa_atexit
Thread model: posix
gcc version 4.3.3 (GCC)
Im not sure exactly how much of that may be relevant to this discussion but ill include it incase.
So what i found doing some google'ing is that lots of people just saying run back trace when GDB halts the program, but i do not get a trace. I dont know if this is because i am cross compiling or what the issue is. Here is a backtrace i got earlier.
Stopped due to shared library event
[New Thread 17266]
[Switching to Thread 17266]
bt
#0 0x96969694 in ?? ()
#1 0x96969696 in ?? ()
#2 0x96969696 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)If anyone has seen this before and knows how i can get the location of the seg fault without having to write custom event handlers i would really appreciate it( even to the last function call in my code would be accurate enough ).
Many thanks
