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.