Linux 新libstdc++；关于遗留系统

我正在尝试将当前的（GCC>=4.6）工具链改装到基于glibc2.3.6的遗留嵌入式ARM/Linux系统上。我已经成功构建了工具链，但现在我的测试程序正在libstdc++中运行，例如：

int main()
{
    int* foo = new int[100];
    delete [] foo;
    return 0;
}

。。。libstdc++静态初始化中的SEGFULTS：

#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]

函数的汇编程序代码转储（匿名命名空间）：\uuuu future\u category\u instance（）： 0x40082764:ldr r3[pc，#264]；0x40082874 0x40082768:推送{r11，lr} 0x4008276c:添加r11、sp、#4 0x40082770：子sp，sp，#64；0x40 0x40082774:mov r1，#0 =>0x40082778:ldr r3[r1，r3] 我将其解释为试图从基址0读取的代码（本例中r1=0，r3为3736），这可能暗示了重新定位问题

当我使用

-static

、

-static libgcc-static libstdc++

或通过LD_LIBRARY路径从我的工具链强制加载libgcc_.so.1和libstdc++.so.6时，就会发生这种特殊的崩溃

---

我几乎被困在这里，如果能提供我的工具链可能出了什么问题的任何线索，以及这是否应该起作用，我将不胜感激。

我的猜测是，它要么是一个已损坏的构建，要么是试图从您的旧系统加载一个库

您可以通过运行

strace

来检查第二个选项，以查看它打开了哪些库文件：

strace your-program

这对于静态链接的二进制文件来说很好，但是如果您想设置

LD\u LIBRARY\u PATH

，则更为棘手，因为这很可能会破坏strace二进制文件。在这种情况下，可以这样尝试：

strace /path/to/ld-linux.so --library-path /path/to/libraries your-program

---

您需要弄清楚什么是

ld linux。因此

在您的系统上被调用。

因此，我现在跟踪到一个似乎破坏了我在这里被迫使用的过时ABI（APCS）的代码生成的问题

---

更改后，我的测试代码现在成功运行。

我已经通过设置LD_DEBUG=all检查了加载的内容，但我觉得没有什么问题。

LD_DEBUG

cover

libdl

？是的。我不认为它加载了错误的代码，我认为它加载的代码是错误的（或者加载方式是错误的…）。