This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
corrupt stack on ARM
- From: Tim D. Hammer <Tim dot Hammer at xerox dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 6 Jul 2011 20:25:34 +0000 (UTC)
- Subject: corrupt stack on ARM
Trying to debug a signal 6, Aborted core dump on a Quatro (armv6/ARM11MP based
SOC/board from Zoran) and getting:
(gdb) bt
#0 0x2ae46238 in ?? ()
#1 0x2ae46204 in ?? ()
#2 0x2ae46204 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I tracked down some older discussions that indicated problems handling ARM
assembler when symbols were not present
(http://comments.gmane.org/gmane.comp.gdb.devel/28921; although that thread
refers to armv7). I replaced the libc and libpthread libraries with unstripped
versions and got no improvement. I also pulled down the latest version of gdb
with the patch in that other discussion.
We are cross-compiling using the WindRiver 3.0 toolchain. libc is 2.8. gdb
originally was 6.5. I have also tried with a patched 7.2 as well as today's 7.3
source.
Interestingly, nm cannot interpret the libc or libpthread unstripped libraries
(File format not recognized). I also have the .debug files for each library and
those are working with nm, although my attempts to utilize them with gdb did not
change the output.
Any and all help/ideas would be appreciated.
Thanks!
.Tim