Linux Fu: Up Your GDB Game!

If you want to buy a car, there are plenty of choices. If you want to buy a jetliner, there are fewer choices. If you want to use the Large Hadron Collider, you have a choice of exactly one. The harder something is to create, the less likely there is to be many of them. If you are looking for a Linux debugger, there are only a few choices, but gdb is certainly the one you will find most often. There is lldb and a handful of non-open commercial offerings, but for the most part you will use gdb to debug software on Linux.

Of course, not everyone’s a fan of gdb’s text-based interface, so there’s no shortage of front ends available for it. In fact, gdb has two potentially built-in interfaces although depending on how you install gdb, you might not have both of them. Of course, if you use an IDE, it very likely is a front end for gdb among other things. But at the core is gdb and — usually — there is a window somewhere that you can stuff gdb commands into. Even emacs — which might be considered the original IDE — can run gdb and gives you a sort-of GUI experience.

No Front End Required

There was a time when Insight was popular. This wasn’t a front end to gdb. It was an actual copy of gdb with a Tk/Tcl GUI built into it. It fell out of favor, though, because of packaging issues, something my old friend Jeff Duntemann covered at length back when everyone sort of dropped it.

However, there is still a way to use gdb a little nicer without a front end. The -tui flag. This gives you not a graphical user interface, but a textual user interface like the one you can see below.

While I’m not always a fan of GUIs, debugging is one place where it makes sense to have a lot of information on the screen at once, so it is one place I will often try to use something a little nicer than a bare command line. The default view just shows your source code and the command window, but you can also turn on a register display, enable a disassembly display, and change the layout of everything. Try the command “layout split” or “layout regs” to see some different displays. The “layout src” command will put things back to how they started. If you want to get serious about using TUI mode, check out the documentation. It is worth noting that you can use “tui enable” to turn this mode on at any time and “tui disable” to turn it off and go back to plain gdb.

Why Not Web?

These days, everything runs in a web browser so why not your debugger? The gdbgui front end does just that. Of course, the debugger isn’t running in the browser, only the user interface which connects to a local server. You can see the program running against an ARM executable using gdb-multiarch in the accompanying figure.

All the front ends, of course, look for the normal gdb executable. But if you are debugging something remotely like an AVR or ARM chip, you’ll need to find the way to point to the correct gdb program. For gdbgui, that’s the -g option on the command line. It wasn’t obvious if there was a way to connect to the server (OpenOCD, in this case) using the extended-remote protocol. By default, at least, it used the standard remote protocol which is less capable.

Another similar choice that runs the interface in the browser is gdbfrontend. It also takes a -g or –gdb-executable option to set a different choice of underlying gdb program. You can see how it looks below.

Like gdbgui, there doesn’t seem to be a way to configure the front end to use the extended remote protocol, which causes some limitations when debugging with OpenOCD. One interesting feature is the collaboration button which lets you draw on the screen, presumably while screen sharing with someone or projecting your screen for a classroom.

Other Choices

Another good-looking option is Seer which does not run in a browser. Note that this is not the same as the seer package in Ubuntu, unfortunately. For seer, you’ll have to exit the first dialog to pop up and head over to Settings to change the gdb executable. However, I had problems setting breakpoints in the GUI. It did seem like breakpoints would work if you used the gdb terminal, but that sort of defeats the purpose. It does look like it has an interesting “array visualizer” if you can get it to work. I settled for a shot of seer debugging a really simple Linux program and it did fine at that.

I suspect that all of these programs work just fine using normal gdb on a regular Linux ELF file. All of the problems were doubtless because I was using OpenOCD as a gdbserver and talking to a remote ARM chip which is probably not something the developers test very often. Even so, the two browser-based tools were able to get the job done, even though they ignored the extended protocol’s features.

Do you care? If you use an IDE that integrates gdb, maybe not. Or maybe you are too tough to use a debugger at all. That’s fine. But for the times you need gdb, these frontends can make you more productive and give you more attention to focus on what really matters: finding the bug.

Honestly, if you are thinking of using the TUI interface, check out the dashboard we talked about earlier this year. If you haven’t gotten your feet wet with gdb remote debugging, Maya Posch has got your back.