1

当使用 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 时会严重失败。（而且我假设其他旨在帮助我在源代码和构建输出之间导航的调试工具会遇到类似的问题）。

有没有一种通用的方法来处理可重定位文件的调试符号？我认为在发布带有调试符号的库的二进制版本时，这应该始终是一个问题。

编辑：

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

  • mount /softwareto /workspace/build: (kcachegrind) 用户可能没有创建权限/workspace

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

4

1 回答 1

0

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

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

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

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

于 2018-05-28T07:48:53.587 回答