Multi Debugging

Many programs these days are written using multiple threads, multiple processes, and multiple languages. Our current debugging solutions don’t cope particularly well with any of those.

gdb supports multiple threads. However, the interface is hard to work with. You have to select which thread you want to look at. Threads are referred to using numbers which are relatively arbitrary; it would be helpful to be able to say things like “show me the server thread.” When a thread releases a lock, it would be helpful to be able to automatically switch to the thread which acquires the lock.

When debugging multiple processes, the most interesting case is handling remote calls between the processes. It would be desirable to be able to switch easily from the process making the call to the process executing the call. Naturally multiple processes may be running on different systems, so this requires communicating with different machines during the debugging session. Multi process core files would also be interesting.

Debugging multiple languages is a difficult case, but one applicable to many web based applications. It’s normal for code to move in and out of a scripting language, such as Python, and underlying C/C++/Java code. In the multiple process case you may also have some code running in a browser written in Javascript.

For code with strong interfaces, multi-process and multi-language debugging is less interesting. However, the reality of today’s programs is that they aren’t written with strong interfaces, and program logic moves between different components. A flexible and powerful debugger could be very useful.

There is a lot of interesting work going on with gdb these days. Making gdb more powerful is hard, but I hope that it will be possible.