gdb instruction traces

> gdb [exe] --batch -x debug.cmds > trace.log 2>&1

with debug.cmds containing:

[prelude for misc setup including probably "b main" and "run"]

disp/i $pc

source stepiN.txt

and stepiN.txt containing N copies of "si\n" (Anyone know of a loop capability in gdb?). I tried to use this to get a good trace of an execution that happened to trail off into oblivion (executing "code" where there is none).

Other ideas for scripts:

[prelude]

b func_you_care_about

source cont_bt_N.txt

where "cont_bt_N.txt" contains N repetitions of

c

bt

i r

...

This will let you know the contexts in which "func_you_care_about" is reached.

This can also be done more simply by setting "commands" after setting the breakpoint (see http://johnnyjacob.wordpress.com/2009/07/07/gdb-scripting-short-article-for-internal-magazine/).

Misc: Just saw a talk on LLVM's lldb. It is also really scriptable. It provides scriptability from python and the ability to evaluate pretty complex C/C++ statements once a breakpoint is reached (e.g., a for-loop with printf to look through an array). One audience member commented that you could pretty much do Valgrind with these tools, but perhaps with higher overheads. Getting good traces with multi-threaded programs may also be a problem. I tried the instruction-by-instruction "stepi", and unfortunately, the trace got stuck in a CompareAndSwap loop.