4

I followed this post to print stack trace How to generate a stacktrace when my gcc C++ app crashes . It works well in x86 linux. Can anyone teach me how to make it work on arm-linux?

I am using arm-linux-gcc 4.4.3.

[root@FriendlyARM /]# ./test1
Error: signal 11:
[0x0]

in x86

mickey@mickeyvm:~/Desktop/workspace/test/testCatchSeg/src$ ./test1
Error: signal 11:
./test1(_Z7handleri+0x19)[0x804876d]
[0xedd400]
./test1(_Z3bazv+0x10)[0x80487c2]
./test1(_Z3barv+0xb)[0x80487e1]
./test1(_Z3foov+0xb)[0x80487ee]
./test1(main+0x22)[0x8048812]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x84de37]
./test1[0x80486c1]

This is how I compile for arm-linux

 arm-linux-g++ -g -rdynamic ./testCatchSeg.cpp -o testCatchSeg
Community
  • 1
  • 1
Mickey
  • 419
  • 7
  • 17
  • Can you post the gcc command line for the ARM compilation? You aren't by any chance trying to run the x86 binary on the ARM target, are you? – Alexandru C. Jun 04 '12 at 07:24

2 Answers2

6

ARM does not store the return address on the stack when branching to a subroutine but rather expects any function calling subroutines to save the link register to its own stack frame before calling other functions, so it is impossible to follow stack frames without debug information.

Simon Richter
  • 28,572
  • 1
  • 42
  • 64
  • That doesn't mean that there is no useful information potentially available though. For example, as android provides on arm for application process crashes, a dump of the present value of the link register, and of the last handful of values on the stack could provide clues for skilled human interpretation - you don't know that all of those values are addresses, but call stack return addresses should be amongst them. This is even more useful if those values are automatically correlated as potential addresses within executable/library mappings and any identifiable symbols therein. – Chris Stratton Jun 04 '12 at 16:56
  • Can you teach how to get more debug information? My aim is debug segmentation fault. I am not familiar with dump or link register. – Mickey Jun 05 '12 at 09:25
  • The best way is to attach a debugger such as gdb when running the program; this way, the SIGSEGV is delivered to the debugger instead and the program frozen right in the illegal access. The debugger can then look at the faulting instruction and map it back to the source line as well as look up the register and stack usage at this point in the debug information, which is sufficient to generate a stack trace. – Simon Richter Jun 05 '12 at 09:54
  • If your program works on x86, you can also run it under valgrind on your PC, there is a certain chance that this shows the error, even if it doesn't lead to a crash due to a different memory layout. – Simon Richter Jun 05 '12 at 09:56
  • My program is running in ARM Linux. I think I have to cross compile debugger fisrt – Mickey Jun 08 '12 at 01:55
  • It is sufficient if you use a cross-compiled gdbserver and run gdb on your host system. – Simon Richter Jun 08 '12 at 06:56
4

I just got backtrace() to work with GCC for ARM. The key for me was compiling with -funwind-tables. Otherwise the stack depth was always 1 (i.e. empty).

jfritz42
  • 5,913
  • 5
  • 50
  • 66