当使用 kcachegrind 或只是objdump -C -l -d somelib.so时，我注意到我的共享库中的某些调试信息不是最新的，这是由于从构建机器的本地文件系统复制到安装的共享网络文件系统的过程。
工作流为：
- 生成计算机签出要
/workspace/build/PROJECT/VERSION/dirs_with_sources的源 - 使用
-g在本地构建 - 生成后，将源复制到
/software/PROJECT/VERSION/dirs_with_sources，将构建的共享库复制到/software/PROJECT/VERSION/InstallArea/ARCHITECTURE/lib
当我现在打开带有objdump -C -l -d somelib.so的共享库时，我看到调试符号如下：
0000000000001a89 <_GLOBAL__sub_I_somesource.cpp>:
_GLOBAL__sub_I_somesource.cpp():
/workspace/build/PROJECT/VERSION/subdir/subsubdir/src/somesource.cpp:33
1a89: 48 83 ec 08 sub $0x8,%rsp
1a8d: be ff ff 00 00 mov $0xffff,%esi
1a92: bf 01 00 00 00 mov $0x1,%edi
1a97: e8 a4 fb ff ff callq 1640 <__static_initialization_and_destruction_0(int, int)>
1a9c: 48 83 c4 08 add $0x8,%rsp
1aa0: c3 retq
这里的文件名不能只是复制和粘贴，因为我没有在我的用户机器上挂载构建目录，需要用software替换/workspace/build。
这很烦人，但在运行时会显着失败，例如 kcachegrind，其中源查找只是失败。(我认为其他旨在帮助我在源代码和构建输出之间导航的调试工具也会遇到类似的问题(。
是否有处理可重定位文件的调试符号的通用方法？我认为在发布带有调试符号的库的二进制版本时，这应该始终是一个问题。
编辑：
我用作解决方法并希望避免作为一般解决方案：
将
/software挂载到/workspace/build：(kcachegrind(用户可能没有创建/workspace的权限从源代码重新编译以获得固定的调试信息：这可能需要比用户愿意投入的更多的编译时间(可能还有用户磁盘((这就是我们首先拥有构建机器和网络安装的部分原因(。
@tom-tromey 对 GDB 的评论也适用于 kcachegrind。在菜单中
设置→配置 KCachegrind→注释→添加
可以添加其他搜索路径，因此指定/software/足以找到源。 我还没有测试如果搜索路径中存在类似的源会发生什么(在原始示例中，同一源文件的多个版本存在于不同版本的目录中(，但实际上从/software/搜索无论如何都太慢了(太多的子目录要搜索(。 出于这个原因，我现在在该菜单中使用/software/PROJECT/VERSION/dirs_with_sources。
根据我对文档的理解，这个 kcachegrind 搜索路径与 gdb 的substitue-path不同(这可能更适合这里的例子(。