Counting machine instructions using gdb

16
votes

I need to estimate the exact starting location of some hotspot in a program, in terms of x86 machine instruction count (so that it can later be run in some emulator/simulator). Is there a way to use gdb to count the number of machine instructions being executed up to a breakpoint?

There are other alternatives of course, I could use a emulation / binary instrumentation tool (like Pin), and track the run while counting instructions, but that would require installing this tool on every platform I work on - not always possible. I need some tool that's available on pretty much any linux machine.

With gdb, I guess it's also possible to run stepi X over large strides as some sort of coarse grained search until we hit the breakpoint, then repeat with reduced the resolution, but that would be excruciatingly slow. Is there another way to do this?

3
x86gdbtrace
GDB is completely unsuitable for this purpose. Use something like PAPI to accurately measure how your application performs. You should have instrumentation tools everywhere you have an editor too, anyway. – Michael Foukarakis
@mfukar thanks, but i'm not sure it's easily available everywhere like GDB is. I also wouldn't say GDB is entirely unsuitable, it seems a really simple feature to add, as it already knows how to step at machine inst resolution - all it needs is to keep track of instruction count somewhere. – Leeor
ptraceing a program in a debugger alters program state which may be vital to performance (cache state, TLB misses, etc). The results you'll get while running a program in a debugger apply only on that situation. – Michael Foukarakis
Why would you you want to count machine instructions? If this is about profiling that's not a very useful measure. – pentadecagon
@pentadecagon, like I said - I need to run a certain section in a simulator (gem5 for e.g.), which can be triggered to start at a given instruction count – Leeor

3 Answers

21
votes

Try this:

set pagination off
set $count = 0
while $pc != 0xyourstoppingaddress
  stepi
  set $count++
end
print $count

Then go get a cup of coffee. Or a long lunch.

6
votes

This is actually only a slight improvement of the usability of Mark's solution.

We can define a function do_count:

define do_count
set $count=0
while ($pc != $arg0)
stepi
set $count=$count+1
end
print $count
end

and then this function can be reused for counting the number of steps over and over again:

set pagination off
do_count 0xaddress1
do_count 0xaddress2

One can even put this definition into .gdbinit (on Linux, on Windows it should be called gdb.ini) in the home-folder, so it becomes available automatically after the start of the gdb (use show user to see, whether the function was loaded).

5
votes

If you actually want a cycle count (maybe as an approximation of instruction count with known IPC), and you're running on bare metal ARM, you might be able to read the cycle counter, see for example Cycle counter on ARM Cortex M4 (or M3)?

In your scenario, I would try Process Record and Replay to obtain the elapsed instruction count (available since GDB 7.0 and improved afterwards):

  1. Start measurement: record btrace (or record full if the former is not available).
  2. continue execution (until a breakpoint, or use next or other commands to step through).
  3. Obtain measurement: info record
  4. Clear recorded results: record stop (recommended as the buffer is of limited size).

Example:

(gdb) record btrace
(gdb) frame
#0  __sanitizer::InitTlsSize () at .../lib/sanitizer_common/sanitizer_linux_libcdep.cc:220
220       void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, "_dl_get_tls_static_info");
(gdb) info record
Active record target: record-btrace
Recording format: Branch Trace Store.
Buffer size: 64kB.
Recorded 0 instructions in 0 functions (0 gaps) for thread 1 (Thread 0xf7c92300 (LWP 20579)).
(gdb) next
226       ...
(gdb) info record
Active record target: record-btrace
Recording format: Branch Trace Store.
Buffer size: 64kB.
Recorded 2859 instructions in 145 functions (0 gaps) for thread 1 (Thread 0xf7c92300 (LWP 20579)).

Limitations:

  • The record buffer has a limited size (this can be increased with set record btrace pt buffer-size <size> for the BTS format above, see the documentation for other types).
  • With record full, not all instructions can be captured. Notably, SSE and AVX instructions are unsupported and will cause gdb to pause execution.
  • There is some overhead while recording every instruction (especially with the full format). Though it should not be as bad as the gdb step approach described in other answers (which has to go through ptrace every time).