问题
I'm currently working on a debugging environment, and I'm have trouble creating valid core files on ARM where the crash that caused a segmentation fault occurred on shared library code.
It seems that when there's a call to a function in a shared library, the frame pointer gets lost.
I've checked all the gcc flags I could think of. I'm not using any optimizations, not using -fomit-frame-pointer and I've tried using -rdynamic, all without success. Also, I'm not using abort(), since I read it is somewhat problematic on ARM since the frame information isn't saved since the function does not return. Instead, I'm using memset(NULL, 0, 1) to get the segmentation fault.
I'm using an arm-cortex_a8-linux-gnuabi toolchain that I compiled myself using crosstool-NG's default cortex-a8 configuration. (gcc 4.4.3, gsb 6.8). On the host machine (Ubuntu), everything works fine.
The output of GDB is like so (after loading all the shared libraries via set solib-search-path.) I omitted unrelevant output for readability.
(gdb) thread apply all bt full
Thread 1 (process 535):
#0 0x402ff624 in memset () from <my libc path>
No Symbol table info available.
#1 0x4011f60c in my_asserting_func () at src1.cc:5
No locals.
Backtrace stopped: frame did not save the PC
src1.cc:
#include <src1.h>
#include <string.h>
void my_asserting_func(void)
{
memset(NULL, 0, 1);
}
main.cc:
#include <src1.h>
int main(void)
{
my_asserting_func();
return 0;
}
Any help would be much appriciated,
Andrew.
PS: using objump, here's the disassembly of the my_asserting_func function:
00000654 <_Z17my_asserting_funcv>:
654: e1a0c00d mov ip, sp
658: e92dd800 push {fp, ip, lr, pc}
65c: e24cb004 sub fp, ip, #4
660: e3a00000 mov r0, #0
664: e3a01000 mov r1, #0
668: e3a02001 mov r2, #1
66c: ebffffb1 bl 538 <_init+0x38>
670: e89da800 ldm sp, {fp, sp, pc}
来源:https://stackoverflow.com/questions/7231089/missing-frames-on-shared-libraries-on-arm