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!

Turned out that the problem was not at all related to the names of the parameters to the VM. Xmx is the right way to grow the heap.This set of parameters does work when put into an eclipse.ini file (for Eclipse 3.5):

-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx1024m

The problem was that Eclipse actually never read its eclipse.ini file, because I had changed the name of the main Eclipse binary. I have several Eclipse installations with different versions active at the same time, and to bring some sanity to shortcuts and Windows start menu items, I started renaming the executables to include the version name. Thus, I had “eclipse-3.5.1.exe” rather than “eclipse.exe” in the problematic case.

It seems that eclipse when starting reads a file like “my-file-name”.ini, and thus all changes to the file “eclipse.ini” has no effect for “eclipse-3.5.1.exe”.

Why do I always find these bugs?

Thanks to Simon Kågströms post (and the even better second-generation with screenshots) about using Eclipse for the Linux kernel, I have a much nicer work environment now for my ongoing work in learning Linux device drivers on PowerPC, which has helped me work my way through several hard-to-figure-out system calls. Here is a screenshot that I found pretty cool… the tool has found the definition and comments for the IRQ registration function:

2009-Feb-01:

I had to rebuild my indexing from scratch in the past weekend, and as a result, I have a word of warning: you have to create a “C project” in Eclipse, if you accidentally create a “Project”, the Eclipse workspace file will have the wrong name (.project instead of .cproject), and the autoconf-to-eclipse script will not work.

For more like this, visit one of my favorite sites, the Worse than Failure.