我正在尝试将当前(GCC> = 4.6)工具链改装到基于glibc 2.3.6的传统嵌入式ARM / Linux系统上。我已成功构建了工具链,但现在我的测试程序在libstdc ++中是segfaulting,例如:
int main()
{
int* foo = new int[100];
delete [] foo;
return 0;
}
... libstdc ++静态初始化中的段错误:
#0 0x40082778 in (anonymous namespace)::__future_category_instance ()
at /path/to/src/gcc-4.6.4/libstdc++-v3/src/future.cc:64
#1 0x40082bb0 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1)
at /path/to/src/gcc-4.6.4/libstdc++-v3/src/future.cc:103
#2 _GLOBAL__sub_I_future.cc(void) () at /path/to/src/gcc-4.6.4/libstdc++-v3/src/future.cc:109
#3 0x400e92b8 in __do_global_ctors_aux () from /path/to/symbols/libstdc++.so.6
#4 0x400627a0 in _init () from /path/to/symbols/libstdc++.so.6
#5 0x4000b5e4 in ?? () from /path/to/sysroot/lib/ld-linux.so.2
#6 0x4000b5e4 in ?? () from /path/to/sysroot/lib/ld-linux.so.2
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
我还有几个例子,但崩溃网站看起来都像这样:
Dump of assembler code for function (anonymous namespace)::__future_category_instance():
0x40082764 <+0>: ldr r3, [pc, #264] ; 0x40082874 <(anonymous namespace)::__future_category_instance()+272>
0x40082768 <+4>: push {r11, lr}
0x4008276c <+8>: add r11, sp, #4
0x40082770 <+12>: sub sp, sp, #64 ; 0x40
0x40082774 <+16>: mov r1, #0
=> 0x40082778 <+20>: ldr r3, [r1, r3]
我将此解释为试图从基地址0读取的代码(r1 = 0,r3在这种情况下为3736),这可能暗示了重定位问题?
当我使用-static
,-static-libgcc -static-libstdc++
或强制加载libgcc_s.so.1和libstdc ++。so.6从我的工具链进行构建时,会发生此特定崩溃LD_LIBRARY_PATH。
我几乎被困在这里,并希望了解我的工具链可能出现什么问题的任何线索,以及这是否应该起作用。
答案 0 :(得分:1)
所以我现在已经跟踪到change in GCC 4.6.0这似乎打破了我在这里被迫使用的过时ABI的代码生成(APCS)。
随着更改的改变,我的测试代码现在成功运行。
答案 1 :(得分:0)
我的猜测是它是一个破坏的版本,或者它正试图从你的旧系统加载一个库。
您可以通过与strace
一起运行来检查第二个选项,以查看它打开的库文件:
strace your-program
这对于静态链接的二进制文件可以正常工作,但如果要设置LD_LIBRARY_PATH
则更加棘手,因为这很可能会破坏strace二进制文件。在这种情况下,请尝试这样:
strace /path/to/ld-linux.so --library-path /path/to/libraries your-program
您需要弄清楚系统中调用的ld-linux.so
。