Displaying each assembly instruction executed in gdb

Question

I currently have a tricky bug that occurs in a place where I don't have access to source or symbols, i.e. I can see the instruction and its address where the crash occurs, but that's about it. What I'd like to do is have gdb run without requiring interaction and display every instruction as it does so, but I've yet to find a way to do it.

What I'm hoping to achieve is something like this:

(gdb) /* some command */
0x2818a7c0: push   %ebp
0x2818a7c1: mov    %esp,%ebp
0x2818a7c3: push   %ebx
0x2818a7c4: sub    $0x4,%esp
...
0x28563622: mov    %esi,0x0(%eax)
Program received signal SIGSEGV, Segmentation fault.

What I've been doing is setting up a display for the program counter, like so:

(gdb) display/i $pc

And then running through the code with stepi:

(gdb) stepi
1: x/i $pc  0x2818a7c0: push   %ebp

However, the crash is hundreds or thousands of instructions away, and I'd like a way to see each one (together, if preferable), without having to hit "enter" that many times. Also, if I were to do it manually, I'd see a (gdb) prompt between each instruction, which is less than desirable.

One route I've briefly looked into is scripting, but my only thought is to setup at main(), have it display and another break (for the next instruction), and then continue, but then I can't use commands within a commands block, so it wouldn't work the way I'm imagining it.

In case it matters, I'm working on FreeBSD.

Answer 1

The following should do what you asked for:

# not strictly required, but you'll likely want the log anyway
(gdb) set logging on

# ask gdb to not stop every screen-full
(gdb) set height 0

(gdb) while 1
 > x/i $pc
 > stepi
 > end

However, this approach to debugging will likely prove futile: there are simply too many instructions executed even in most trivial programs.

A better approach might be to run the program until crash, attempt to understand what current function is doing and who calls it, and setting breakpoints appropriately.

On x86, you can often deduce function boundaries even in fully stripped executable.

Another thing you'll want to look at is strace/truss output, so you can see what system calls immediately precede the crash point.