Running unit tests under gdb: Part I

Our build system usually runs all the unit tests under valgrind. It does this by preceding the invocation of the compiled unit test with $(RUN_TEST) as in this simplified version:

RUN_TEST?=valgrind
my_unittest.pass : my_unittest
    $(RUN_TEST) my_unittest
    touch $@

This means that it's easy to run the test without valgrind by invoking

make RUN_TEST= my_unittest.pass

This can be useful when you know the test is going to fail and you don't want the huge amount of output that valgrind will spew when you abort() from the depths.

Sometimes it would be handy to run the unit tests under gdb but unfortunately invoking a program under gdb is not the same as invoking it normally so RUN_TEST=gdb doesn't work. Compare:

valgrind myprog myargs...

with:

gdb myprog
run myargs...

So, what's needed is a gdb wrapper script that turns the former method of invocation into the latter. It turns out that it's possible to do even better than that. The following script runs the program under gdb and if it succeeds just exits normally so that the next test can be tried. If the program breaks due to an abort then the if statement unfortunately produces an error message but it does have the intended effect — you're left at the gdb prompt.

Here's my run-under-gdb script:

#!/bin/sh
cmds=`tempfile -p rug`
prog=$1
shift
: > $cmds
echo "run $1 $2 $3 $4 $5 $6 $7 $8 $9" >> $cmds
echo 'if $_exitcode == 0' >> $cmds
echo '  quit' >> $cmds
echo 'end' >> $cmds
if gdb -x $cmds $prog; then
 rm -f $cmds
else
 result=$?
 rm -f $cmds
 exit $result
fi

It's not ideal — it corrupts quoting of its arguments and arbitrarily limits the number of arguments but it does work. Part two contains an improved script that solves these problems and provides other fixes.