Linux 技巧：重定向 stderr 和 stdout 输出到 gdb 窗口

文介绍了一个实用 gdb 调试技巧。 它结合实际例子，一步一步示意如何重定向 stderr 和 stdout 到 gdb窗口，使得查看应用程序的输出信息更为方便，从而提高调试者的工作效率。

简介

本文介绍了一个实用 gdb 调试技巧。 它结合实际例子，一步一步示意如何重定向 stderr 和 stdout 到 gdb窗口，使得查看应用程序的输出信息更为方便，从而提高调试者的工作效率。

回页首

问题

为了调试基于 Eclipse 的 Java 和 C++ 混合的应用程序时，通常同时使用 Eclipse 和 gdb 来分别调试 Java 和 C++ 代码。此时，被调试程序的标准输出( stdout )和标准错误输出( stderr )取决于这个该程序的启动方式。如果程序是在 Eclipse 的 IDE 环境下启动的，那默认情况下 stderr 和 stdout 都会输出在 Eclipse 的 console 窗口下，如果这时又需要用 gdb 来调试 C++ 的代码，那为了查看输出的调试信息，还不得不切换到另外一个窗口（比如 Eclipse 的 console窗口）去查看，然后再切回来继续调试，这是不是很不方便呢？

回页首

解决之道

下面本文将介绍个一个简单的方法用以重定向 stderr 和 stdout 到指定的目的地，包括正在使用的 gdb 窗口。

由于这个方法是基于 gdb 提供的基本而又强大的两个功能之上的，所以在介绍它之前，先简单介绍一下 gdb 的这两个功能。

使用 call 命令调用外部函数

GDB 提供的 call 命令允许调试者在当前函数调用栈的栈顶调用函数，犹如在被调试的程序中执行的一般。比如想关闭某个文件(文件描述符为 fd )，那只需要在 gdb 中输入：

(gdb) call (int)close(fd)

有了它，gdb 就可以具有很强大的功能，因为只要把所需要的功能写成一个函数编译进应用程序，调试时候在 gdb 中 call 该函数便可。

利用 .gdbinit 来自定义 gdb 命令

GDB 在启动的时候会按一定的路径顺序(通常是先当前目录而后用户目录)寻找 .gdbinit 文件，一旦找到，就会自动执行里面的命令。这个功能允许用户把常用的一些命令放在这个文件里，这样就不用每次进入 gdb 后再去手动执行这些命令。事实上，.gdbinit 就是一个脚本，甚至可在里面把常用的若干 gdb命令序列定义成一个新命令，这样只要在 gdb 里面输入这个新命令就等于自动执行了被定义的那个命令序列。

另外，如果用户已经在 gdb 里后，再去修改 .gdbinit ，只要通过：

(gdb) source  ~/.gdbinit

便可以让那些新增加的改动生效。

重定向 stdout和 stderr

首先，打开一个终端窗口，先用 ps 命令查到所需进程的 pid 。

$ ps ax | grep HelloWorld(要调试的应用程序名)
13522  ??  S    134:47.01 /Users/yyq/projects/1210/HelloWorld
24730  p5  S+     0:00.00 grep Notes

上面列出的第一行中的13522，就是 HelloWorld 的 pid 。

接着，我们使 gdb 连接上这个应用程序。如下：

$ gdb   –pid=13522

或者可以先运行 gdb ，然后用 attach 命令，如下：

$gdb
$atta 13522

不出意外的话，接下来就可以在 gdb 窗口调试了。

可以试一下看看是不是输出信息不在 gdb 窗口中。

(gdb) call (void)printf(“\n Is this string printed on gdb window\n”)

这时在 gdb 窗口是看不见这个输出的。 为了跟踪查看某些重要的调试信息，得不停地切换到别的窗口去看，很不方便。

解决的方法如下：

先关闭 stdout ，和 stderr 对应的文件描述符。

(gdb) call (int)close(1)
(gdb) call (int)close(2)

然后使用以下命令查看一下当前 gdb 窗口所在的虚拟终端。

(gdb) shell tty
/dev/tty5

这时再重新打开 stdout 和 stderr ， 把它们和 gdb 窗口所在的虚拟终端关联起来。

(gdb) p (int)open("/dev/ttyp1", 2) 
$1 = 1 
(gdb) p (int)open("/dev/ttyp1", 2) 
$2 = 2

如果这两个命令执行结果不是如上结果（1和2），意味着 open 执行失败，需要重新进行 close 和 open.

另外，如果把这里的 ”/dev/ttyp1” 替换成目标文件名，便可将 stderr 和 stdout 重定向到该文件。

接下来，重新执行如下命令：

(gdb) call (void)printf(“\n Is this string be printed on gdb window?\n”)
Is this string be printed on gdb window?

这次输出到了 gdb 窗口，也证明成功重定向了被调试程序的 stdout和 stderr . 以后就可直接在 gdb 窗口中看到所有的输出信息，勿需再切换窗口。

如果每次都要运行这么多命令，还是较为繁琐，此时可以利用 .gdbinit 来简化用户输入：把这一系列命令定义一个新命令，放到 .gdbinit 文件里，然后在 gdb 里执行这个命令便可。

关于在 .gdbinit 中定义 gdb 新命令的语法可以参考 dW 上其他的文章。下面就针对重定向问题，看 .gdbinit 是如何通过引入新命令来简化用户输入。其实, 只需在 .gdbinit 文件里，增加如下脚本：

def  redirect 
call (void)close(1) 
call (void)close(2) 
call (int)open($arg0, 2) 
call (int)open($arg0, 2) 
end

上面这段脚本定义了一个新命令: redirect ，就是重定向的意思。

之后，当重启 gdb (或者运行 source~/.gdbinit )，并且连接到要调试的应用程序后. 用以下简单的两步就可达到重定向的目的：

第一步， 仍是得到这个 gdb 窗口所在的虚拟终端：

(gdb)shell tty 
/dev/ttyp3

接着就可以调用 .gdbinit 中定义的命令了：

(gdb)redirect("/dev/ttyp3")
$1=1 
$2=2

为了易于理解记忆，甚至可以按如下方式为该命令增加帮助信息。

把下面这段脚本紧接添加到刚才 redirect 所对应的 end 后面

document redirect 
redirect("argument"), this is used to switch stderr and stdout to gdb window.
The argument is the name of gdb window.
end

这样，在 gdb 窗口中，就可以使用 help 命令来查看这个命令的帮助信息了：

(gdb) help redirect
this is used to switch stderr and stdout to gdb window. 
The argument is the name of gdb window.

即时刷新 stdout 和 stderr

由于系统有时会对输入输出会进行缓存，因此有可能会碰到如下情况：执行了输出语句，但还是不见输出。尤其是在调试 Java/C++ 混合程序时容易发生这种情况，比如在 JNI 代码中的printf 就很可能被缓存后再输出。这种系统缓存机制很不利于调试程序，因为调试信息的及时输出很重要，很多时候要利用这些输出信息来判断程序的行为是否正常。

为了解决这个问题，可以调用 fflush:

(gdb)call (int)fflush(0)

这样所有的缓冲都会得到立刻刷新，包括 stdout 和 stderr . 调试者就能马上看到前面执行的输出的结果。

回页首

总结

gdb的命令很丰富，功能也很多，巧妙地利用它们可以大大地提高调试者的工作效率。本文通过利用 gdb 的 call 命令和 .gdbinit 文件的扩展功能，提出了一个简单有效的方法, 用以重定向被调试程序的 stdout 和 stderr ，以及如何及时刷新显示输出结果。

参考资料

• GDB：GNU Project Debugger：从 GNU 软件的发源地获得有关该程序的更多信息。
  
  
• 逆向工程社区：访问这个网站以获得有关使用 GDB 来调试进程的更多信息，并为有兴趣了解程序如何工作的用户社区作出贡献。

作者简介

		恽益群，IBM 中国软件开发中心软件工程师，东南大学硕士。专长基于 MAC OS X/Linux的应用程序开发, GUI 应用程序移植等。

		余锦，IBM 中国软件开发中心高级软件工程师，清华大学硕士。专长基于MAC OS X/Linux的应用程序开发, GUI 应用程序移植等。