https://felix-knorr.net/blog/using_gdb_directly.html

Skip links

  * Skip to primary navigation
  * Skip to content
  * Skip to footer

Menu

  * Home
  * About
  * Categories

Felix' Blog
Felix' Blog

A blog about programming, science, and everything else that I might
come up with.
Subscribe for notification mails when I publish a new post

Debugging with GDB

Felix G. Knorr
February 27, 2022

Categories

  * programming

Tags

  * c
  * gdb

My first programming language was C++ and for a long time, I was
using Visual Studio Express in Windows. When I had to debug
something, I would click on the line number to set a breakpoint and
press F5. Maybe I'd add some variables to the watch window, and press
some F-keys a couple of times. Recently, I switched jobs and I'm now
mostly developing firmware in C. Since I switched to using Linux and
Vim ~7 years ago, I needed to update my debugging workflow. I
actually didn't find a neat tutorial that covers the whole picture,
so I figured I could write one myself.

During the last 5 years, I mostly worked with Python, and I really
like debugging in Python. You'd just put a breakpoint() function call
into your code somewhere and repl into the program. I wanted to see
how close I get to that in C. As C is not an interpreted language, my
hopes weren't that high, but it turns out debugging in C is quite
comfortable. As a bonus, you can use GDB not only to debug C and C++,
but also Rust, Nim, and probably any language that respects the C-ABI
(althoug I don't know this for a fact).

GDB Basics

First, we need a program to debug. Let's take this one:

// program.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

void print_product(int a, int b) {
    int product = a * b;
    printf("Product: %d\n", product);
}

void print_arguments(int argc, char **argv) {
    for (int i = 1; i < argc; i++) {
        printf("%s ", argv[i]);
    }
    printf("\n");
}

int main(int argc, char **argv) {
    print_arguments(argc, argv);
    srand(time(NULL));
    for (int i = 0; i < 10; i++) {
        print_product(rand(), rand());
    }
    return 0;
}

To debug the program, it's important that it contains debugging
symbols. To add debugging symbols when compiling with gcc add the -g
flag. So let's compile this program:

gcc -g -o program program.c

We can now debug this program by running:

gdb program

this will launch us into a repl. To run the program until it hits the
main function, type start. Now you have the typical debugger actions
that you can execute by typing them into the repl. You can go to the
next line by entering n (of course you have to press return too), s
to step into the current function call, r to run until you hit a
breakpoint, and some more. To set a breakpoint, type b <line> where
<line> is the line number you want it in. If your project consists of
multiple files, you'll have to type b <filename>:<line> however,
<filename> does not need to be a complete path, just the name is
enough. Btw, gdb allows for tab completion. Alternatively you can set
a breakpoint to a function like this b <functionname>.

To see the context of a variable, we can use p like p product if we
break at line 6. But we can also evaluate nearly arbitrary c
expressions e.g. p product * 5.

Using gdb scripts

This is still not nice though, now we'd have to enter all breakpoints
over and over again, when we restart the debugging session. But there
is a way out of this: gdb scripts. If you invoke gdb with the -x
option, you can pass it a file containing gdb commands, that it
should execute.

gdb -x gdbscript program

we can now write our breakpoints into the script, e.g.

# gdbscript
b 6
b 11
r

And now our breakpoints are stored. But there is more to it.
Typically I want to check some variables, and I'm not very interested
in running the program further than that. Let's say, we wanted to see
the value of the product variable, for all loops, and dont care about
the rest:

# gdbscript
b 6
commands
    p product
    c
end

run

and then run gdb with --batch like this:

gdb -x gdbscript program --batch

Now gdb will quickly print out the value of product for all
iterations, and exit again. A commands statement after a breakpoint
will execute all contained commands once a breakpoint is hit. The
last command, the c means continue and will resume the program flow
until the next breakpoint is hit, once the breakpoint was hit the
last time, gdb will end execution thanks to the --batch parameter.

Another cool example: let's say, for whatever reason, we are
interested in the value of product only during the third call of
print_product(). (Which is of course silly, since the program prints
it anyway, but in real world debugging, a situation like this might
arise)

set $n = 0

b 6
commands
    set $n = $n + 1
    if $n == 3
        printf "Product is: %d\n", product
    else
        c
    end
end

run

As you can see we define a variable $n and use it to count up, and
print our required information in the third round. After the third
round, gdb quits automatically thanks to --batch. For a more complete
tour through gdb's scripting capabilities, I recommend the tutorial
on adacore.com: part 1 and part 2.

The .gdbinit file

There is a script, that gdb will always implicitly load if it exists:
~/.gdbinit You can put functions you use often in there, or
configuration. Mine looks like this:

set width 0
set height 0
set print pretty on
set confirm off

Setting width and height to 0, will prevent gdb from paging long
outputs, the third line makes gdb prettify the output, and the last
line prevents it from asking if we really want to quit.

Conclusion

This is largely what I have. In general, I'm quite happy with the
power and flexibility. It might be a little more work than placing a
breakpoint in an IDE, but you get so much more out of it. Also, in
IDEs I always found it annoying to call the debugger with arguments,
because you'd have to find the right options dialog. Here you can
simply append them to the debugger invocation:

gdb -x gdbscript --batch --args program --flags and some args

Also, if you require a more complex setup for debugging, e.g. because
you have to start other programs too, you can put all of that
together in a bash script.

Of course, there is much more to know about gdb, and this is barely
an introduction.

Share Tweet LinkedIn Reddit

Previous

Markdown Note - The best Note app around
 

(c) 2022 Felix' Blog. Powered by Jekyll & So Simple.