Question

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

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

在嵌入式操作系统上，我们有一个繁忙的盒子，里面有很少的工具，但我们注意到，在命令正常运行时，在客户端连接后，cpu使用率从20％上升到100％（我不知道如何......甚至更多）。第一印象是应用程序错误，但在Fedora机器上的调试会话期间从未注意到，如果您在/ proc / 任务 / 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复制到嵌入式（libstdc ++和libc）。相同的行为
逆转进程：将所需的库复制到源树并强制链接器使用这些库。启动应用程序（编译器端）后，在重新生成... 的实例后，错误消息终止。

其他信息：如果有用：在两个库上应用ldd -v libgcc_s.so.1（在嵌入式系统上不可用），我得到以下结果：

HOST LIBRARY：

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

EMBEDDED LIBRARY：

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％。然后，您可以将问题缩小到库或服务器代码。有关perf here

的更多信息

libgcc_s.so冲突可能会导致使用异常的CPU超载？

1 个答案: