libgcc_.so冲突可能导致使用异常的cpu过载？ 我开发了一个嵌入式I~6兼容环境的C++服务器应用程序，不需要交叉编译器。由学院开发的动态库，大量使用异常技术。该库需要实现网络通信，并且，一旦在目标文件系统中复制，在客户端连接后，会导致异常终止，并显示一条公共消息：在抛出一个实例后终止。。。即使libstdc++在嵌入式操作系统上可用

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

在嵌入式操作系统上，我们有一个busybox，工具少且减少，但我们注意到，通过命令正常运行时间，在客户端连接后，cpu使用率从20%提高到100%（我不知道如何提高…甚至更多）。第一印象是一个应用程序错误，但在Fedora机器上的调试会话期间从未注意到，如果您在/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与嵌入式系统混合可能会导致一些奇怪的副作用，但我没有任何线索

因此，我开始寻找另一种部署服务器的方法：

将其他必需的库从Fedora3复制到嵌入式so（libstdc++和libc）。同样的行为

反向过程：将所需库复制到源树，并强制链接器使用这些库。正在启动应用程序（编译器端）。错误消息在引发。。。重生了

其他信息： 如果有用：在两个库上应用ldd-v libgcc_.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\u信息：

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

---

如果您的嵌入式系统有足够多的最新版本的Linux内核，您可以尝试使用Linux性能计数器（perf）。安装它们时，在嵌入式系统上运行

perf record./server

。这将在服务器退出时生成性能数据。之后，您可以在与文件相同的目录中使用

perf report

分析文件。它将显示每个库和可执行符号使用了多少CPU%。然后，您可以将问题缩小到库或服务器代码。有关性能的更多信息

如果您的嵌入式系统有足够的最新版本的Linux内核，您可以尝试使用Linux性能计数器（perf）。安装它们时，在嵌入式系统上运行

perf record./server

。这将在服务器退出时生成性能数据。之后，您可以在与文件相同的目录中使用

perf report

分析文件。它将显示每个库和可执行符号使用了多少CPU%。然后，您可以将问题缩小到库或服务器代码。关于性能的更多信息

我很难准确说出这里的问题，但您确定这不适合unix.stackexchange.com或superuser.stackexchange.com吗？对不起，也许我糟糕的英语会引起一些混乱。我认为解决我的问题的主要目标可能在于关注如何正确编译这个应用程序，以便允许异常处理，但避免将库从一个so复制到另一个so。我很难准确地说出这里要问什么，但是你确定这不适合unix.stackexchange.com或superuser.stackexchange.com吗？对不起，也许我糟糕的英语会引起一些混乱。我认为解决我的问题的主要目标可能是关注如何正确编译这个应用程序，以便允许异常处理，但避免将库从一个so复制到另一个so。我将perf_版本复制到嵌入式系统中，但它声明libelf。因此，我也复制了它，但我得到了错误libelf.so.1：无法处理TLS数据。无论如何，如果某个库消耗cpu，我应该在进程cpu%中看到它？可能问题出在内核空间中，异常涉及其中。。。或者我完全错了？我在编译器端运行perf并比较了在空闲模式下生成的报告和使用客户端连接生成的报告：在第一种情况下，应用程序的主循环消耗大约1,8%，而内核主要涉及调用syscenter\u pass\u esp（8.6%）和其他系统调用。在第二种情况下，对于连接的客户机，libgcc_s.so以18%（第一次报告中甚至没有提到）的比例获得极点位置，随后是5.4%的syscenter_和libstdc++（3.9%）。这一结果强化了我的怀疑。@Cappelli嵌入式系统和fedora3上有不同的CPU吗？你能给我看看这两台机器的

/proc/cpuinfo

吗？Fedora3是在虚拟化环境中运行的。在实验室里，我发现了一张带有（准）交叉编译环境的旧cd，即使cpu名义上是i386完全兼容的，实际上直到今天我们才需要它。该产品已过时，供应商不再支持该产品。该环境包括安装在嵌入式系统中的库，因此我的下一步是说服libtool使用那些（少数）具有先例的库。我将perf_版本复制到嵌入式系统中，但它声明libelf.so，我也复制了它，但我得到了错误libelf.so.1:无法处理TLS数据。无论如何，如果某个库消耗cpu，我应该在进程cpu%中看到它？可能问题出在内核空间，包括