If you want to buy a car, there are plenty of choices. If you want to buy an airliner, there are fewer choices. If you want to use the Large Hadron Collider, there is only one to choose from. The harder something is to create, the less likely there will be a lot of it. If you are looking for a Linux debugger, there are few choices, but gdb is certainly the one you will find most often. There are lldb and a handful of unopened commercial offerings, but most of the time you’ll be using gdb to debug software on Linux.
Of course, not everyone is a fan of gdb’s textual interface, so there’s no shortage of interfaces 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 course, if you’re using an IDE, it’s most likely a front end for gdb, among other things. But at its core is gdb and – usually – there’s a window somewhere where you can insert gdb commands. Even emacs – which could be considered the original IDE – can run gdb and gives you some kind of graphical experience.
No front end required
There was a time when Insight was popular. It was not a frontend for gdb. It was a true copy of gdb with a built-in Tk/Tcl GUI. It fell out of favor, however, due to packaging issues, something my old friend Jeff Duntemann covered at length back when everyone let him down.
However, there is still a way to use gdb a little more pleasantly without a frontend. The -tui flag. This does not give you 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 a place where it makes sense to have a lot of information on screen at once, so it’s a place I’ll often try to use something a little nicer than a simple command line. The default view just shows your source code and the command window, but you can also enable a register view, enable a disassembly view, and change the layout of everything. Try the “layout split” or “layout regs” command to see different displays. The “layout src” command will put things back the way they started. If you really want to use TUI mode, consult the documentation. It should be noted that you can use “tui enable” to enable this mode at any time and “tui disable” to disable it and return to regular gdb.
Why not the Internet?
Everything works in a web browser these days, so why not your debugger? The gdbgui the front-end does exactly that. Of course, the debugger doesn’t run in the browser, just the UI that connects to a local server. You can see the program running on an ARM executable using gdb-multiarch in the attached figure.
All frontends, of course, look for the normal gdb executable. But if you’re debugging something remotely like an AVR or ARM chip, you’ll need to find a way to point to the correct gdb program. For gdbgui, it’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 efficient.
Another similar choice that runs the interface in the browser is gdbfrontend. It also needs a -g or –gdb-executable option to set a different choice of underlying gdb program. You can see what it looks like below.
Like gdbgui, there doesn’t seem to be a way to configure the frontend to use the extended remote protocol, which causes some limitations when debugging with OpenOCD. A nice feature is the collaboration button which lets you draw on the screen, probably when screen sharing with someone or projecting your screen for a classroom.
Another attractive option is Seeing that does not run in a browser. Note that this is unfortunately not the same as Ubuntu’s seer package. To see you will need to exit the first dialog to appear and head to Settings to edit the gdb executable. However, I had problems setting breakpoints in the GUI. It looked like breakpoints would work if you were using the gdb terminal, but that defeats the purpose. It looks like it has a nice “table viewer” if you can get it to work. I was content with a seer shot debugging a very simple linux program and it went well.
I suspect all of these programs work just fine using normal gdb on a standard Linux ELF file. Any problems were probably caused by me using OpenOCD as the gdbserver and talking to a remote ARM chip, which the devs probably don’t test very often. Even so, both browser-based tools were able to get the job done, albeit skipping extended protocol functionality.
Are you interested? If you’re using an IDE that integrates gdb, maybe not. Or maybe you’re too tough to use a debugger. It is very good. But for those times when 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’re considering using the TUI interface, check out the dashboard we talked about earlier this year. If you are unfamiliar with gdb remote debugging, Maya Posch is here for you.