I’ve been doing a lot of debugging lately. I am very unhappy
with the current state of debuggers.

For instance, right now I’m looking into a code generation bug in
gcj. I’m debugging the generated code to understand what is going
wrong. I want to set a breakpoint in a function that is called just
before the failure, since I think perhaps this function is computing
something incorrectly. However, this function is called thousands of
times. What I’d like to do is set a breakpoint that is conditional on
who is calling my function — but of course this isn’t possible. (Cue
some evil hack involving looking at the frame pointer…)

People have talked about scriptable debugging for years, but we’re
still stuck with gdb’s lame not-quite-a-language. Ugh. Meanwhile I’m
spending the day like an interpreter, repeatedly hitting “continue;
up” until I see what I want. I should probably just write some elisp
and let Emacs do it.

gcjx

Debugging gcjx has been mixed. On the one hand, gdb’s C++ support
is lacking in some ways, so certain bugs have been very hard to debug.
On the other hand, gcjx tracks locations for all the objects it builds
in its model. This means it is very easy to, say, put a breakpoint in
the code generator that triggers when gcjx is generating code for a
particular line in the original source code. I never did find a way
to do this reliably while debugging the old gcj. (Cue someone to clue
me in.)

This feature of gcjx turned out to be handy for debugging by
accident. Still, it puts me in mind to design in debugger support
features like this in my next program.