Gcc 如何使用nm或objdump和/或任何其他可用工具来确定.so文件中有问题的函数/方法？

问题是： 从RH5（gcc 4.1.2和GLIBC 2.5）到RH6（gcc 4.4.7和GLIBC 2.12）的迁移问题

详情： 我正在将一个大项目从RH5（GCC4.1.2）迁移到RH6（GCC4.4.7），所有的东西都可以编译和链接，没有任何问题

在RH5上编译的代码在两台主机（RH5和RH6）上都运行良好

但是，在RH6上编译的代码在这两个平台上都不起作用

没有运行时错误，只是我运行的许多回归测试中的一个失败了

这是一个复杂的因素：我的代码创建了一个模拟机器（微处理器）。运行回归测试的软件/固件是一个在这个模拟机器上运行的软件，我没有调试这个固件

当我在RH6主机上编译代码时，错误被注入 我能够将问题精确定位到两个对象文件（.o），它们被链接以创建共享对象文件（.so），这是我模拟机器的一部分

如果我在RH6机器上编译代码（带有gcc 4.4.7的机器，可执行文件在我的回归测试中失败），然后添加在RH5（gcc 4.1.2）上编译的两个有问题的（.o）文件，并使用这两个.o文件重新编译（.so）文件（共享对象），那么一切正常，回归测试顺利通过；顺便说一句，它同时在RH5和RH6机器上通过

我正在使用“nm”和“objdump”试图找出什么是/是有问题的函数/函数或库/库或其他东西

我的问题是: 1-我如何利用这些工具（nm和/或objdump）来真正确定罪魁祸首 （如果我在从RH5和RH6生成的.so文件上运行上述命令，并比较输出文件，我可以看到很大的差异，但由于每个编译器及其上下文的具体情况，无法判断预期的差异以及可能存在的问题）

2-有没有其他工具可以真正帮助我调查和解决这个问题

3-如果我将RH6中的.so文件和RH6中的.so文件的nm/objdump输出与RH5中的两个.o文件进行比较，它们看起来很相似，我看不到试图解开这条纠结线的尽头，那么如何查看这些输出文件并尝试解决问题呢

---

我非常感谢您的评论、建议和贡献。

不知道为什么您不能正常调试。从检测到的问题开始反向工作。为什么不使用-O0-g3编译以保留调试符号并禁用优化，然后使用gdb或其他调试器在运行时调试代码？感谢Jester和Ixe的反馈，使用调试器并单步执行代码是我更愿意作为最后一个资源进行探索的选项，因为这是一个怪物代码。此外，通过分解.so文件，我发现使用RH5编译的带有两个模块（.o）的.so文件有一个对不同名称函数“\uu\strtoul”的函数调用_internal@plt"而失败的.so文件调用了“strtoull@plt“。函数如下所示：0000000000007928:7928:ff 25 ca 46 30 00 jmpq*0x3046ca（%rip）#30bff8 792e:68 51 00 00 00 pushq$0x51 7933:e9 d0 fa ff ff jmpq 7408 000000000000 8078:8078:ff 25 72 43 30 00 jmpq*0x304372（%rip）#30c3f0 807e:68 d0 00 pushq$0xd0 8083:e9 e0 f2 ff jmpq 7368