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

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    [=10=]x8,%rsp
    1a8d: be ff ff 00 00        mov    [=10=]xffff,%esi
    1a92: bf 01 00 00 00        mov    [=10=]x1,%edi
    1a97: e8 a4 fb ff ff        callq  1640 <__static_initialization_and_destruction_0(int, int)>
    1a9c: 48 83 c4 08           add    [=10=]x8,%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 的 substitue-path 不一样（这可能更适合这里的示例）。

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

read debug symbols when source file was relocated

c++

gdb

kcachegrind