Full automatic call tracing in GDB

hacker_compStarting off working on an existing project can be tedious, specially when you are trying to implement a new feature. In case of many projects, the debug mode becomes handy. But what if the logs aren’t enough to get you to the point of execution? I am working on a similar project where I needed to understand the code flow to capture a filesystem event. The program would wait till such an event occurs.

Before someone suggests strace land ltrace, here’s what these two utilities do:

strace: trace system calls and signals
ltrace: intercepts and records the dynamic library calls which are called by the executed process and the signals which are received by that process. It can also intercept and print the system calls executed by the program.

In my case I need the function call trace of the program in a specific scenario for better understanding of the code.

I started with the usual tool, GDB, and ran the program. As I didn’t know where to add a breakpoint, I let the program run till it waits, crashed it using <Ctrl-c>, and issued bt full. That took me a little past main().

I was wondering if there’s a tool that can trace the full sequence of calls by automatically stepping in each function call. Eventually, I found a very helpful C program called gdbwalkthrough. I have uploaded a copy here, feel free to download it. It automates GDB to send ‘s’ and then read GDB’s output, continuously, and then output the result to a text file (myfile2.txt) as well as the terminal.

To compile the program, run:

$ gcc -o gdbwalkthrough gdbwalkthrough.c


$ ./gdbwalkthrough <application full path> [application arguments]

For example:

$ sudo ./gdbwalkthrough /usr/local/bin/sysdig -A -c echo_fds "fd.filename=passwd"

This script can be modified easily to step only through a set of lines, or to step only a predefined number of times. Replace



int x=1000;

[Original source, the script is a modified version]

Similar software:

2 thoughts on “Full automatic call tracing in GDB”

  1. that’s an interesting idea, but do you know you can ‘drive’ GDB through its Python API ?
    that would be so much easier for your job, like

    while True:
    print(gdb.execute(“step”, to_string=True), file=…)

    you just have to improve the infinite loop, and that would be most of it !


Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s