Contributing to the Reversible GDB

Last week, I finally got the last “OK” from the maintainers of GDB, the Gnu Debugger, indicating that my contribution to the GDB project was accepted. This is my first contribution to an open-source project, and the piece of code that has my name on it is positively puny. It is actually not really code at all, it is just a piece of documentation, for the extensions to the GDB-MI command set needed to support reversible debugging. The actual code doing the work was contributed by a colleague of mine, Tomas Holmberg, credit where credit is due.

So what is the significance of this code?

Essentially, there are three main communications protocols or channels involved with GDB. There is the direct command-line interface familiar to most GDB users. There is the gdb-serial protocol for talking between a GDB and a GDB server on some remote machine.There is the GDB-MI, Machine Interface, protocol used to directly control a GDB debugger from another program. In particular, Eclipse uses GDB-MI to control GDB, when using GDB as the debugger back-end for Eclipse.

With GDB-serial, a remote machine can also be a simulator, hardware emulator, or anything else that presents the right interface to GDB. Indeed, using gdb-serial is the most common way to attach “anything” to be debugged by GDB. Simics, VMWare, and many other virtual platform solutions support gdb-serial as a way to get the power of the GDB debugger (source code lookup, scripting, and the smarts to deal with complex languages like C++ and Ada, and much more) for debugging code running on the virtual machine. The requirements on a gdb server are very simple, it really is just start/stop/step, and setting breakpoints and modifying memory.

When GDB 7.0 came out, support for reverse debugging was the really big piece of news. With the initial release of 7.0, you could access reverse debug from the GDB command-line interface, driving either local process record/replay targets, or remote gdb-serial targets. Simics was among the first simulators to support reverse debugging over gdb-remote, since the command set for doing reverse debug was essentially contributed by Virtutech with the initial release of reverse debugging in Simics back in 2005. Michael Snyder got that code into the reversible GDB development from the start, we can claim no credit for getting it into the mainline GDB.

However, the MI interface was missing reverse debugging commands, and I have been involved in getting that support into the GDB source tree. It has taken quite a while longer than I expected, and it has been quite an interesting journey.

When we started the work back in late 2008, we had a set of MI commands that was used in a Virtutech-specific patch to GDB 6.8. This set of commands and their supporting code was submitted to the GDB mailinglist in early 2009, but got rejected by the maintainers. In the end, we changed the commands according to the wishes of the maintainers, and added test cases and documentation (my bit). This patch was then resubmitted, reviewed, and updated in a few more iterations. The final update was to align the code with the latest code updates to GDB.

Along the way, Tomas and I had to sign some legal papers to assign copyright to the code we contributed to the FSF. For some reason, the first batch of papers got lost on their way across the Atlantic to us to get signed, forcing a delay of some months.

So, now, we have GDB with MI supporting reversible debugging. Finally, I hope it arrived in time to help the Eclipse people get reverse debugging into Eclipse as a standard feature.

For me, even though this process sometimes felt like it would never end, it has been very interesting.

• The process is frustrating in that if you disagree with a maintainer on some issues, things can stall until you realize the errors of your way and repent. We had such a discussion on the style of the GDB reverse commands, both in MI and the main command-line interface. The viewpoint that I supported lost, which I think is a shame, but at least the functionality is there.
• Related to that, the discussions on the gdb mailinglists have been quite interesting. If you have relevant points, people will tend to listen. The value of ideas is judged from how well they work, and usually not from set agendas or corporate grand strategies.
• Sometimes, you really miss the function of an overall product manager for GDB. Somewhere or someone that takes responsibility for the overall direction of the product. Today, we have a very productive anarchy, which certainly works, but is a bit unfamiliar to someone used to commercial and planned software development.
• Compared to some other standards work that I have been involved in, GDB is a much faster process. Collaboratively improving a shared body of code is a nice way to work, but it might be very hard to port over to company-driven future-pointing standards. For example, if no code exists, the model hardly works.
• The user-interface design coming out of the GDB community is clearly quite geeky and often not what I think a UI designer would come up with. The GDB reverse commands, with a “set direction” command is one example. Another interesting one starts here, with my input here.

Happy reversible debugging, all!