在重新安装 f27 (netinstall) 之后,我注意到许多 pkgs 将小文件放在/usr/lib/.build-id/
dir 中。一开始我以为我以某种方式为 dnf 启用了一些晦涩的“调试”模式,但即使
$ dnf download httpd
Run Code Online (Sandbox Code Playgroud)
获取一个带有/usr/lib/.build-id/*
文件的 rpm 。
我不记得在以前的 Fedora rels 中有这个。
Ste*_*itt 28
/usr/lib/.build-id
包含已安装软件包的主要构建 ID 文件。在 Fedora 27 之前,这些与调试文件/usr/lib/debug
一起存在于 . 在 Fedora 27 中,引入了一项更改以允许并行安装多个调试信息包。该更改的一部分涉及在它们匹配的包中传送主要的 build-id 文件,以确保它们与已安装的二进制文件匹配。
许多发行版中都使用调试信息包,为用户提供一种在必要时安装调试信息的方法,而不会让每个人都膨胀二进制文件。在构建和链接程序或库时,可以使用调试信息构建它,然后调试器可以使用这些信息将二进制文件中的位置与其源代码中的位置进行映射;但是这些信息占用了很多空间。所以调试信息通常在二进制文件被打包之前从二进制文件中剥离出来。近年来,strip
并objcopy
得到了增强,以便可以单独提取和存储调试信息——这就是调试信息包的构建方式。所需要的只是确保二进制文件及其调试信息对应的某种方式,这就是构建 ID 的用武之地——它们是由以下公式计算的唯一标识符ld
(在--build-id
那里寻找)在二进制文件的重要部分。“主要构建 ID 文件”是从构建 ID 到相应的二进制文件或调试信息文件的符号链接;它们允许实现双向映射,以便可以有效地调试核心转储(在 参考资料 部分,在二进制文件本身中有一个从二进制文件到它们的构建 ID 的链接.gnu_debuglink
)。您可以在Fedora build-id 功能描述 中找到所有这些背后的推理的详细解释。
归档时间: |
|
查看次数: |
7031 次 |
最近记录: |