Writing tests that use GDB - how to capture output?

Question

I am trying to write tests that interact with GDB but am having trouble capturing the output. I would like for a log file to be generated which looks like what would have been seen in a terminal had the test been executed by hand. GDB is proving to be very stubborn when it comes to capturing its output however.

I've been able to write Expect scripts which are able to interact with GDB and whose output can be redirected to a log file but I don't want to write my tests in TCL. I'm hoping to use Groovy, which is compatible with Java. For some reason with Perl's Expect and ExpectJ the program output always goes to the terminal and can't be redirected to a file.

I tried starting a GDB process from Java using ProcessBuilder and it mostly works but the output of print statements never appear on stdout and can't be captured. I thought if Expect works then I'd launch expect from Java and have it interact with GDB but in this case most of the program output is lost, never appearing in the stdout of the created process.

So my question is, how can I write a test in Groovy (Java would be fine as well) which interacts with GDB and can capture all of the output?

Pseudo-code:

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

Log file:

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

Program exited normally.
(gdb) quit

Answer 1

One possibility is that the GDB output is being dumped on standard error and you are only capturing standard output. You should be able to fix this with a redirect, something like this I think:

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

A second guess is that it may be worth checking what "show interactive-mode" says in the working and non-working cases. If they differ try "set interactive-mode off" before you do anything else.

A third option is to use GDB's logging facility to write the log file ("set logging file " and "set logging on") and avoid having to capture the output yourself.

Answer 2

If your test involves using gdb to actually debug something, as opposed to testing gdb itself, you should probably look into using the gdb/mi interface.