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

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/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

这里的文件名不能仅仅被复制和粘贴，因为我的用户计算机上没有安装build目录，需要用software替换/workspace/build 。

这足够令人讨厌，但是在运行例如kcachegrind时，如果源查找刚刚失败，则会严重失败。 （并且我假设其他旨在帮助我在源代码和构建输出之间导航的调试工具也会遇到类似的问题）。

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

编辑：

我用作解决方法并希望避免作为一般解决方案的方法：

• 将/software挂载到/workspace/build ：（kcachegrind）用户可能没有创建/workspace的权限

• 从源重新编译以获取固定的调试信息：这可能需要比用户愿意投资的更多的编译时间（可能还需要用户磁盘）（这部分是为什么我们首先拥有构建机器和网络安装的原因）。

Answer 1

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

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

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

根据我对文档的了解，此kcachegrind搜索路径与gdb的substitue-path （这可能更适合此处的示例）。