Debugging the debugger

After working on gdb for a while, I’ve noticed a funny flaw: gdb is too good at debugging itself.

I often hear stories of disappointment from gdb users. It doesn’t scale well. It doesn’t handle threads well. It only has a vague understanding of the C++ that users insist on typing at it. That was my experience, too, when I was working on C++ (or worse: Java) programs.

But gdb itself doesn’t use any of these features. It is written in more or less plain C. It is single-threaded. It is not too big. It does not rely on many shared libraries. So, as a gdb developer, I find it is pretty easy to forget that it has flaws.

I once heard about a C++ compiler written in C++ where, in order to counteract this same sort of problem, its developers mandated that the compiler use every existing C++ feature.

For fun try to picture code review on that project. “Bob, this patch looks ok, but I think you should use operator overloading and exceptions here.”

That said, I think the “share the pain” theory is one reason — among several — to change gdb’s core to be implemented in C++.

Another way to combat complacency would be to debug other programs while working on gdb. I find this pretty hard to do, though. I tend to allocate more and more of my time to hacking my main project at the expense of the secondary one.

I noticed this as well, although I don’t think it is possible for a debugger to be too good. Once my mips harware watchpoint support was minimally functional, I used the new capabilities to find bugs in themselves. I was a bit amazed at how well it worked.