I'm having trouble getting a back trace for a crash on a Raspberry Pi 3 dev-board (RPI3). The RPI3 is a low-end ARMv8 with a Broadcom SoC, with CRC32 extensions, but without Crypto extensions.
The program is the test suite for the Botan Crypto and TLS C++ library. The program was built with the following flags. The --debug-mode means the program was built with symbols (-g) and without optimizations (no -O).
./configure.py --cc=gcc --debug-mode --cpu=armv8-a --cc-abi-flags="-march=armv8-a+crc \
-mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -fno-omit-frame-pointer"
Attempting to get a back trace on a SIGABRT results in the following:
...
DLIES XOR ran 12 tests all ok
[New Thread 0x765bf450 (LWP 3674)]
pure virtual method called
terminate called without an active exception
Thread 2 "botan-test" received signal SIGABRT, Aborted.
[Switching to Thread 0x765bf450 (LWP 3674)]
0x765fef70 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt full
#0 0x765fef70 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0x76600324 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#2 0x00000020 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
libc6-dev is installed. I understand FP is the frame pointer (R11), SP is the stack register (R13), LR is the link register (R14) and PC is the program counter (R15). I'm not clear if the above message from GDB means R11 or R14 is corrupt, or if something else is going on.
How do I recover the frame pointer for broken back trace and restart the back trace prior to the corruption?
According to artless_noise at ARM: link register and frame pointer, the basic frame layout is:
fp[-0] saved pc, where we stored this frame.
fp[-1] saved lr, the return address for this function.
fp[-2] previous sp, before this function eats stack.
fp[-3] previous fp, the last stack frame.
many optional registers...
I don't know how to (1) spot a good frame pointer, (2) glue things together and (3) restart the back trace.
The OS is 32-bit Raspbian, which may have something to do with the issue because it was built for ARMv7 with hard floats.
As far as I know, there's nothing stopping a program from using ARMv8 instructions in this configuration. In fact, other test programs are running fine in a similar configuration. But I don't rule out an ABI problem that did not surface under the other test programs.
