0

我正在努力RHEL WS 4.5。

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

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

我将所有这些都安装在一个测试虚拟机上（从相同的 RH 基础映像创建），并且可以确认我的更改已包含在内。

但是对于更复杂的执行，我在 mtrace.c 中崩溃了……但是 gdb 找不到调试信息，所以我没有得到行号信息，我实际上无法调试失败。

根据日期，我想我可以确认在 /usr/src/debug/glibc-2.3.6/ 中的测试系统上安装了调试信息

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

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

我的感觉是 glibc 可能不是在启用调试的 rpmbuild 下构建的。我已经查看了 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 但这两个报告为被 file 命令剥离。

4

2 回答 2

0

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

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

没有相同的版本；它们不可能来自相同的 -debuginfo RPM。

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

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

另请注意，您实际上不必让所有这些工作来调试您的问题。在RPMBUILD目录中，您应该能够找到 glibc 构建目录，带有 full-debug libc.so.6。只需将该库复制到您的 VM 中，您就不必担心debuginfoRPM。

于 2012-10-31T05:12:11.187 回答
0

尝试验证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 更容易。

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

于 2012-11-03T09:46:42.143 回答