If you want to buy a car, there are many 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. The harder it is to create something, the less likely it is to have many. If you are looking for a Linux debugger, there are only a few choices, but GDB is one that you will often find. There are lldb and a handful of non-open commercial offers, but for the most part you will use GDB to debug software in Linux.
Of course, not everyone is fond of gdb’s text-based interface, so there’s no shortage of front-end. In fact, gdb has two possible built-in interfaces, although depending on how you install gdb, you may not have both. Of course, if you use an IDE, it’s probably the front end of gdb among other things. But the main part contains gdb and – usually – somewhere there is a window where you can stuff gdb commands. Even emacs – which can be considered as the original IDE – can run gdb and give you a kind of GUI experience.
No front end required
There was a time when Insight was popular. This gdb was not a front end. It was an actual copy of gdb with a Tk / Tcl GUI. Although it fell out of favor due to packaging problems, my old friend Jeff Duntman covered the length when everyone dropped it.
However, there is a way to use GDB a little better without the front edge. – You flag. It does not give you a graphical user interface, but a text user interface that you can see below.
Although I’m not always a fan of GUI, debugging is a place where it is understandable to have a lot of information on the screen at once, so this is a place where I will often try to use something a little more beautiful than a bare command line default view just your source code and The command window appears, but you can turn on a register display, enable disassembly display, and change the layout of everything. Try the “Layout Split” or “Layout Regs” command to see some different displays. The “layout src” command will return things to how they started. If you want to get serious about using TUI mode, check out the documentation. Note that you can use “tui enabled” to turn this mode on at any time and use “tui inactive” to turn it off and go back to plain GDB.
Why not the web?
Nowadays, everything runs in a web browser so why not your debugger? gdbgui does just that. Of course, the debugger does not run in the browser, only the user interface that connects to a local server. You can see the program running in contrast to an ARM executable using gdb-multiarch in the accompanying image.
All front edges, of course, look for general GDB executables. But if you are remotely debugging something like an AVR or ARM chip, you need to find a way to point to the right gdb program. For gdbgui, this is the -g option on the command line. It was not clear if there was a way to connect to the server (OpenOCD, in this case) using the extended-remote protocol. By default, at least, it uses standard remote protocols that are 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 preference for the built-in gdb program. You can see how it looks below.
Unlike gdbgui, there seems to be no way to configure the front end to use the extended remote protocol, which creates some limitations when debugging with OpenOCD. An interesting feature is the collaboration button that lets you draw on the screen, perhaps when sharing a screen with someone or projecting your screen for a classroom.
Another good option is Seer which does not run in the browser. Note that this is unfortunately not the case with Ubuntu’s Sear package. For viewers, you need to exit the first dialog to pop up and go to settings to change GDB executable. However, I had trouble setting the breakpoint in the GUI. Breakpoints seemed to work if you use GDB terminals, but this kind of purpose is defeated. Looks like it has an interesting “array visualizer” if you can make it work. I decided to take a shot at debugging a really simple Linux program and it worked out well.
I suspect that all of these programs work fine using regular GDB in regular Linux ELF files. All the problems were undoubtedly because I was using OpenOCD as a gdbserver and talking to a remote ARM chip that developers probably don’t check often. Nevertheless, two browser-based tools were able to accomplish the task, although they overlooked the features of the extended protocol.
Do you care If you use an IDE that integrates gdb, maybe not. Or maybe you have a hard time using a debugger. That’s fine. But when you need GDP, these frontends can make you more productive and give you more focus to focus on really important things: finding bugs.
Honestly, if you’re thinking of using the TUI interface, check out the dashboard we talked about earlier this year. If you haven’t wet your feet with GDB remote debugging, Maya Posh has got your back.