1

我正在尝试编写与 GDB 交互但无法捕获输出的测试。我希望生成一个日志文件，如果手动执行测试，它看起来就像在终端中看到的那样。然而，在捕获其输出时，GDB 被证明是非常顽固的。

我已经能够编写能够与 GDB 交互并且其输出可以重定向到日志文件的 Expect 脚本，但我不想在 TCL 中编写我的测试。我希望使用与 Java 兼容的 Groovy。由于 Perl 的 Expect 和 ExpectJ 的某些原因，程序输出总是到终端并且不能被重定向到文件。

我尝试使用 ProcessBuilder 从 Java 启动 GDB 进程，它大部分都可以工作，但打印语句的输出永远不会出现在标准输出上，也无法被捕获。我想如果 Expect 有效，那么我会从 Java 启动 expect 并让它与 GDB 交互，但在这种情况下，大部分程序输出都会丢失，永远不会出现在创建进程的标准输出中。

所以我的问题是，如何在 Groovy 中编写一个测试（Java 也可以），它与 GDB 交互并可以捕获所有输出？

伪代码：

process = "gdb -q".execute()
waitForPrompt()
send("file exec")
waitForPrompt()
send("run")
send("quit")

日志文件：

(gdb) file exec
Reading symbols from exec...done.
(gdb) run
Starting program: exec
<... output ...>

Program exited normally.
(gdb) quit
4

2 回答 2

1

一种可能性是 GDB 输出被转储到标准错误中，而您只捕获标准输出。你应该可以通过重定向来解决这个问题，我认为是这样的：

 process = "gdb -q 2&>1".execute()

第二个猜测是，检查“显示交互模式”在工作和非工作情况下所说的内容可能是值得的。如果它们不同，请在执行任何其他操作之前尝试“关闭交互模式”。

第三种选择是使用 GDB 的日志记录工具来写入日志文件（“set logging file”和“set logging on”），避免自己捕获输出。

于 2010-02-23T20:01:00.927 回答
1

如果您的测试涉及使用 gdb 实际调试某些东西，而不是测试 gdb 本身，您可能应该考虑使用 gdb/mi 接口。

于 2010-02-23T20:45:08.567 回答