Question

我正在研究RHEL WS 4.5。

我已经获得了匹配此系统的glibc源rpm，打开它以使用rpm2cpio获取其内容。

在该树中工作，我已经为mtrace.c创建了一个补丁（我想添加更多的堆栈回溯级别）并将其合并到spec文件中并创建了一组新的RPM，包括debuginfo rpms。

我在测试vm（从相同的RH基础图像创建）上安装了所有这些，并且可以确认我的更改已包含在内。

但是由于执行起来比较复杂，我在mtrace.c中崩溃了...但是gdb找不到调试信息，所以我没有得到行号信息而我实际上无法调试失败。

基于日期，我想我可以确认在/usr/src/debug/glibc-2.3.6 /

中的测试系统上安装了调试信息

我试过了 sharedlibrary libc* 在gdb中，它告诉我符号已经加载。

我的测试包括一个本地构建的python，并且为python找到了完整的符号。

我的感觉是，在启用调试的情况下，可能没有在rpmbuild下构建glibc。我查看了glibc.spec文件，甚至用

构建

_enable_debug_packages

定义为1，看起来可能会影响结果。我对rpmbuild构建步骤中调用的配置脚本的评论没有给我任何提示。

嗯...刚刚找到/usr/lib/debug/lib/libc-2.3.4.so.debug 和/usr/lib/debug/lib/tls/i486/libc-2.3.4.so.debug 但这两个报告都被文件命令剥离。

Answer 1

您似乎正在安装不匹配的RPM：

/usr/src/debug/glibc-2.3.6
刚找到/usr/lib/debug/lib/libc-2.3.4.so.debug

没有相同的版本;他们没有办法来自同一个-debuginfo RPM。

这两个报告都被文件命令剥离。

这些应该不显示为已剥离。要么它们没有正确构建，要么你的strip被破坏了。

另请注意，您实际上并不需要完成所有这些工作来调试您的问题。在RPMBUILD目录中，您应该能够找到glibc构建目录，并使用完全调试libc.so.6。只需将该库复制到您的VM中，您就不必担心debuginfo RPM。

Answer 2

尝试验证mtrace.c的调试信息确实存在。首先看看GLIBC的单独调试信息是否知道名为mtrace.c的编译单元：

$ eu-readelf -w /usr/lib/debug/lib64/libc-2.15.so.debug  > t
$ grep mtrace t
           name                 (strp) "mtrace.c"
             name                 (strp) "mtrace"
 1     0     0         0         mtrace.c
 [10480]  "mtrace.c"
 [104bb]  "mtrace"
 [5052] symbol: mtrace, CUs: 446

然后看看GDB是否实际上从glibc-debuginfo RPM中找到了源文件：

(gdb) set pagination off
(gdb) start # pause your test program right after main()
(gdb) set logging on
Copying output to gdb.txt.
(gdb) info sources

退出GDB，然后在gdb.txt中grep for mtrace，你应该找到像/usr/src/debug/glibc-2.15-a316c1f/malloc/mtrace.c

这样的东西

这适用于GDB 7.4。我不确定RHEL 4.5附带的GDB版本是否支持上面使用的所有命令。从源代码构建上游GDB实际上比Python更容易。

尝试向mtrace添加strack跟踪时，请确保不要直接或间接在GLIBC malloc挂钩中调用malloc()。

需要来自更新源的rpmbuild的GLIBC调试信息

2 个答案: