如何调试像 printf 这样的标准 c 库函数？

Question

我想调试 printf 函数，所以当我进入 printf 函数（gdb 调试器）时，它向我展示了这个：

__printf (format=0x80484d0 " my name is Adam") at printf.c:28
28  printf.c: No such file or directory.

这是什么意思？

当我再次开始 step 时，会有更多这样的陈述。

请帮助我理解这一点。

Answer 1

我认为这很清楚。 有一个gdb期望源代码的地方，所以下载glibc的源代码并将其放在那里。 我认为错误消息包含完整路径。

如果它是一个 linux 发行版，它实际上相当简单，因为通常也会提供源包。 否则你需要自己找到源代码，注意它必须与用于编译 c 库组件的完全相同，而不仅仅是相同的版本，因为分发者经常对源代码进行更改。

Answer 2

好吧，为了让调试器向您展示编译成您正在使用的二进制文件的代码，您需要在某处使用原始代码。

你似乎没有那个，所以你的调试器找不到它。

请注意，您通常不想调试 std 库函数的源代码，而只想调试它们的调用方式。 为此，操作系统的常用“调试符号”包是最佳的。

Answer 3

正如其他人所回答的那样，GDB 无法找到源文件。

对于 C 运行时库，Linux 发行版可能会提供您可以安装的debuginfo RPM，它可能允许 GDB 查看文件。 例如：

 $ yum search glibc-debuginfo

...

 glibc-debuginfo.x86_64 : Debug information for package glibc glibc-debuginfo-common.x86_64 : Debug information for package glibc

...

glibc包和glibc-debuginfo是一对匹配的。 没有明确的依赖关系，但是glibc-debuginfo包将无法工作，除非它与相同版本的glibc匹配。

如果您在某处解压了源代码，但不是 GDB 期望它们所在的位置，您可以尝试使用directory或set substitute-path命令让 GDB 知道源代码的位置。

directory命令告诉 GDB 在它试图查找的任何源文件路径之前添加一个前缀。 例如，如果源树实际上位于/tmp ，则可以使用：

(gdb) directory /tmp

set substitute-path命令用于告诉 GDB 将源文件路径中匹配的前缀替换为不同的路径前缀。 例如，如果编译的源文件在/build/path/source.c ，但在调试时源文件实际上在/usr/home/alice/release-1.1/source.c ，那么您可以使用：

(gdb) set substitute-path /build/path /usr/home/alice/release-1.1

该命令假定您只指定了完整的路径名，因此它不会在/build/pathological/source.c上执行替换。