I know about strace and ltrace, but that only tells me what system calls and library calls a process is executing, respectively. I would like to know exactly what instructions a process is executing. Either assembly, or some sort of middle ground between C and assembly if that is possible. Assuming the binary hasn't been compiled with debug symbols, so leaning toward the first option as more likely.

Use case: process appears to be hung, no output from strace or ltrace. Determine if process is doing "something". I realize this might be difficult to determine, as I imagine this is analogous to solving the halting problem. However, it might be possible to gather useful data.

Second use case: curiosity. It would be interesting to dump the entire list of assembly instructions to a text list.

My guess is that I can use gdb to do this, but not sure how, as this is less about debugging a program I have written and more about using gdb to check on the health of a running process.

OS is CentOS 6.


2 Answers 2


You can do this with gdb: commands ni and si run a single instruction at time. Command n runs the next line of code, for most values of "next". For n (and the corresponding s) you have to have compiled so that debugging symbols appear in the executable.

This stackoverflow answer gives a couple of methods of doing this more-or-less visually.

The gdb command: display/i $pc shows you the instruction before it executes. display $pc show the line of code bfore n or s executes it.

  • Use gdb -p <pid> to attach to the process.
    – Ángel
    Jul 30, 2014 at 8:57

Run ps -l on the process ID and check the S (“state”) column. If the state is R, then your process is executing code. If the process remains in state R and strace doesn't show it executing any system call, then the process is trapped in a very long, possibly infinite computation. If the process is and remains in state D, then it is blocked in a system call. For more information about process states, see What does this process STAT indicates?, What does the "interruptible sleep" state indicate? and What if 'kill -9' does not work?.

If the process is running a long computation, you can use Gdb (or another debugger) to see what it's doing. If the executable lacks debugging information (which is usually the case if you didn't compile the program especially for that), then the debugger will only be able to show you machine instructions; if the executable contains debugging information, you'll be able to see the names of functions in stack traces and so on. To attach Gdb to the process, run gdb /path/to/executable 1234 where 1234 is the process ID. The command s lets you execute instructions one at a time. Unless you're a programmer and are somewhat familiar with what the program is supposed to be doing, there's little chance that you'll get useful information out of Gdb in this scenario.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .