我正在尝试将当前的工具链(GCC >= 4.6)升级到基于glibc2.3.6的遗留嵌入式ARM/Linux系统上。我已经成功构建了工具链,但是现在我的测试程序正在libstdc++中分段错误,例如:
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++或通过LD_LIBRARY_PATH从工具链强制加载libgcc_s.so.1和libstdc++.so.6时,就会发生这种特殊的崩溃。
我被困在这里了,我很想知道我的工具链可能出了什么问题,以及这是否应该起作用。
发布于 2013-11-10 17:39:04
因此,我现在已经追踪到一个GCC 4.6.0的变化,它似乎破坏了过时的ABI被迫在这里使用的代码生成(APCS)。
随着更改的逆转,我的测试代码现在成功运行。
发布于 2013-11-06 14:07:44
我的猜测是,这要么是一个坏的构建,要么它试图从您的旧系统加载一个库。
您可以通过与strace一起运行来检查第二个选项,查看它打开了哪些库文件:
strace your-program对于静态链接的二进制文件来说,这很好,但是如果您想设置LD_LIBRARY_PATH,则需要更复杂的操作,因为这很可能会破坏strace二进制文件。在这种情况下,可以这样做:
strace /path/to/ld-linux.so --library-path /path/to/libraries your-program您需要弄清楚您的系统上调用了什么ld-linux.so。
https://stackoverflow.com/questions/19800531
复制相似问题