Here is something what a hack is, I'm a little confused to post it. But if you only need one-time, it can do well enough so that you can get the information you need. There really should be a better way.
You can define a silly little gdb script that executes step or next commands a certain number of times:
# file: step_mult.gdb define step_mult set $step_mult_max = 1000 if $argc >= 1 set $step_mult_max = $arg0 end set $step_mult_count = 0 while ($step_mult_count < $step_mult_max) set $step_mult_count = $step_mult_count + 1 printf "step #%d\n", $step_mult_count step end end
(I used the step instead of next without much reason, just change it to whatever you need.)
Then you can run this command (with an extra counter) and it will display each step or next .
Here is an example of a program that will crash when trying to dereference a NULL pointer:
#include<stdio.h> int x[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8,9, 10 }; int* p[11]; int main() { int i; for (i = 0; i < 11; ++i) { p[i] = &x[i]; } p[5] = 0; for (i = 0; i < 11; ++i) { printf( "*p[%d] == %d\n", i, *p[i]); } return 0; }
Here the gdb session (on Windows) debugs this program and uses the step_mult script:
C:\temp>gdb test.exe GNU gdb (GDB) 7.2 ... Reading symbols from C:\temp/test.exe...done. (gdb) source c:/temp/step_mult.gdb (gdb) start Temporary breakpoint 1 at 0x401385: file C:\temp\test.c, line 23. Starting program: C:\temp/test.exe [New Thread 5396.0x1638] Temporary breakpoint 1, main () at C:\temp\test.c:23 23 for (i = 0; i < 11; ++i) { (gdb) step_mult 70 step
Unfortunately, since the script does not stop when segfault occurs, gdb decides to just stop debugging the program, so you cannot make any additional useful requests. But a magazine can be useful.
I am sure there are many ways to make a script more intelligent. Unfortunately, I have no idea how to do this, and user level documents for GDB do not seem too useful for these details. It would be best if the script could detect segfault or signal, and just stop, instead of relying on some arbitrary account. I assume that the gdb / MI interface, or perhaps even the Python scripting interface, may have a good mechanism, but I don't know anything about them.
After the first start, you can use the displayed account (37 in my example) and restart the program and give an account that is just shy of where it crashed before and take control manually.
As I said, this is not particularly beautiful - but it can lead you there .