Question

当使用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

此处的文件名不能只是复制和粘贴，因为我的用户计算机上没有安装构建目录，需要用/workspace/build替换software。

这很烦人，但在运行时却显着失败，例如kcachegrind，源查找失败。（我假设其他用于帮助我在源代码和构建输出之间导航的调试工具也会遇到类似的问题。）

是否有一般处理可重定位文件的调试符号？我认为在运送带有调试符号的库的二进制版本时，这应该始终是一个问题。

编辑：

我使用了什么作为解决方法，并希望避免作为一般解决方案：

将/software挂载到/workspace/build：（kcachegrind）用户可能没有权限创建/workspace
从源代码重新编译以获得固定的调试信息：这可能需要比用户愿意投入更多的编译时间（可能还有用户磁盘）（这部分原因是我们在构建机器和网络中安装了第一名）。

Answer 1

@ tom-tromey对gdb的评论也适用于kcachegrind。在菜单中

设置→配置KCachegrind→注释→添加

可以添加其他搜索路径，因此指定/software/就足以获取找到的源代码。我还没有测试过如果搜索路径中存在类似的源（在原始示例中，同一源文件的多个版本存在于不同版本的目录中）会发生什么，但实际上从/software/搜索的速度太慢了（要搜索的子目录太多）。出于这个原因，我现在在该菜单中使用/software/PROJECT/VERSION/dirs_with_sources。

根据我对文档的理解，这个kcachegrind搜索路径与gdb＆＃39; s substitue-path（这可能更适合这里的示例）不同。

重定位源文件时读取调试符号

1 个答案: