c++ - libgcc_s.so 冲突会导致 cpu 过载使用异常？

Question

我为嵌入式 i386 兼容环境开发了一个 C++ 服务器应用程序，因此不需要交叉编译器。由同事开发的动态库，(大量)使用异常技术。要求该库实现网络通信，并且一旦复制到目标文件系统中，在客户端连接后，会导致中止并显示以下常见消息:在抛出...的实例后终止即使libstdc++ 在嵌入式操作系统上可用。

经过几次尝试，包括库的静态链接，我们显然找到了一个解决方案，只需将在 Fedora3 虚拟机上编译时使用的 libgcc_s.so.1 复制到嵌入式文件系统，并使用环境变量 LD_LIBRARY_PATH=< 启动服务器em>fedora lib 的路径。

在嵌入式操作系统上，我们有一个 busybox，工具很少而且减少了，但是我们注意到，通过命令 uptime，在客户端连接之后，cpu 使用率从 20% 上升到 100%(我不知道是怎么回事...甚至更多)。第一印象是应用程序错误，但在 Fedora 机器上的调试 session 期间从未注意到它，如果您在/proc/task/status 上看到，您将看到此日志:

    Name:   taskname
State:  S (sleeping)
SleepAVG:       97%
Tgid:   589
Pid:    589
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0
VmSize:     3396 kB
VmLck:         0 kB
VmRSS:      1604 kB
VmData:      492 kB
VmStk:        84 kB
VmExe:        84 kB
VmLib:      2512 kB
VmPTE:        20 kB
Threads:        1
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000080000000
SigIgn: 0000000000001004
SigCgt: 0000000380004a02
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff

所以即使客户端断开连接，我也无法弄清楚谁在大量使用 CPU。如果服务器在 Fedora 机器上启动，则不会出现此行为。我怀疑将 Fedora3 libgcc_s.so.1 与嵌入式系统混合使用会导致一些奇怪的副作用，但我没有任何线索。

于是我开始寻找另一种部署服务器的方式:

1. 将其他所需的库从 Fedora3 复制到嵌入式 so(libstdc++ 和 libc)。相同的行为

2. 逆向过程:将所需的库复制到源代码树并强制链接器使用这些库。启动应用程序(编译器端)错误消息在抛出...的实例后终止重生。

附加信息:如果有用:在两个库上应用 ldd -v libgcc_s.so.1(在嵌入式系统上不可用)我得到以下结果:

主机库:

    libc.so.6 => /lib/tls/libc.so.6 (0x00694000)
/lib/ld-linux.so.2 (0x0067b000)

Version information:
/lib/libgcc_s.so.1:
    libc.so.6 (GLIBC_2.2.4) => /lib/tls/libc.so.6
    libc.so.6 (GLIBC_2.1.3) => /lib/tls/libc.so.6
    libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6
/lib/tls/libc.so.6:
    ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
    ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
    ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
    ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2

嵌入式库:

    libc.so.6 => /lib/tls/libc.so.6 (0xf6ec3000)
/lib/ld-linux.so.2 (0x0067b000)

Version information:
./libgcc_s.so.1:
    libc.so.6 (GLIBC_2.1.3) => /lib/tls/libc.so.6
    libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6
/lib/tls/libc.so.6:
    ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
    ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
    ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
    ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2

有人有什么解释或建议吗？谢谢

一个。卡佩利

有关处理器类型的更多信息:

编译器主机/proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Xeon(TM) CPU 3.40GHz
stepping    : 1
cpu MHz     : 3390.524
cache size  : 1024 KB
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36
              clflush dts acpi mmx fxsr sse sse2 ss nx pni
bogomips    : 6471.68

嵌入式机器/proc/cpu_info:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 4
model           : 9
model name      : 486 DX/4-WB
stepping        : 4
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu
bogomips        : 65.40

Answer 1

如果你的嵌入式系统有足够新版本的 Linux 内核，你可以尝试使用 Linux 性能计数器(perf)。当您安装它们时，请在您的嵌入式系统上运行 perf record ./server。这将在服务器退出时生成 perf.data。之后，您可以在与文件相同的目录中使用 perf report 分析文件。它将显示每个库和可执行符号使用了多少 CPU%。然后您可以将问题缩小到库或您的服务器代码。有关性能的更多信息 here