1

GDBと相互作用するテストを作成しようとしていますが、出力のキャプチャに問題があります。手作業でテストを実行した場合に端末で見られたようなログファイルを生成したいと思います。ただし、GDBは、出力のキャプチャに関しては非常に頑固であることが証明されています。

GDBと対話でき、出力をログファイルにリダイレクトできるExpectスクリプトを作成できましたが、TCLでテストを作成したくありません。Javaと互換性のあるGroovyを使いたいと思っています。何らかの理由で、PerlのExpectおよびExpectJでは、プログラム出力は常にターミナルに送られ、ファイルにリダイレクトできません。

ProcessBuilderを使用してJavaからGDBプロセスを開始しようとしましたが、ほとんど機能しますが、printステートメントの出力がstdoutに表示されず、キャプチャできません。Expectが機能する場合は、Javaからexpectを起動して、GDBと対話させると思いましたが、この場合、プログラム出力のほとんどが失われ、作成されたプロセスのstdoutに表示されません。

だから私の質問は、GDBと相互作用してすべての出力をキャプチャできるGroovy（Javaも問題ありません）でテストを作成するにはどうすればよいですか？

擬似コード：

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

1つの可能性は、GDB出力が標準エラーでダンプされており、標準出力のみをキャプチャしていることです。あなたはリダイレクトでこれを修正することができるはずです、私が思うこのようなもの：

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

2番目の推測は、動作している場合と動作していない場合に「showinteractive-mode」が何を言っているかを確認する価値があるかもしれないということです。それらが異なる場合は、他のことをする前に「インタラクティブモードをオフに設定」してみてください。

3番目のオプションは、GDBのログ機能を使用してログファイル（「ログファイルの設定」および「ログの設定」）を書き込み、出力を自分でキャプチャする必要がないようにすることです。

于 2010-02-23T20:01:00.927 に答える
1

テストでgdb自体をテストするのではなく、実際に何かをデバッグするためにgdbを使用する場合は、おそらくgdb/miインターフェイスの使用を検討する必要があります。

于 2010-02-23T20:45:08.567 に答える