
Debugging a Debugger - id_ris
http://www.idrisr.com/2015/10/12/debugging-a-debugger.html
======
userbinator
_It 's a really powerful way to debug as you can automate much of the
debugging process and do things that aren't practical without scripting._

IMHO when debugging software needs to be automated to the point that a library
needs to be written (and itself debugged), there's an underlying problem which
can't be solved with adding more layers of complexity - as that will only
introduce _more_ bugs. When these bugs are in the software you're using to
debug, things can quickly take a turn for the worse.

Is that code really taking the user's input (a string), getting object
addresses and offsets (numbers) from that, then converting those into strings
to build a command string, which then gets parsed back into numbers for the
debugger to ultimately use to create a watchpoint? I think that is itself a
good example of how the "more code, more bugs" principle can apply: all this
superfluous conversion code has introduced a bug.

Here's a good article about that, although it doesn't mention the situation
where the bugs you introduce end up being in the software you need to use to
remove bugs...

[http://blog.codinghorror.com/the-best-code-is-no-code-at-
all...](http://blog.codinghorror.com/the-best-code-is-no-code-at-all/)

~~~
quotemstr
> IMHO when debugging software needs to be automated to the point that a
> library needs to be written (and itself debugged),

I've hacked plenty of GDB. It's just a program like anything else. Why
wouldn't you want to debug it? There's nothing mystical or special about it.
When you combine th features you describe with code (which are, in fact, quite
non-trivial) with code to look up symbols, deal with remote gdbserver
instances, papering over extreme differences between operating systems and
executable formats, you end up with a very complex program that has the same
maintenance needs as any other.

~~~
bulutsuzku
Of course you_can_do_everything_in_assembler.

Nobody discuss about mystical or special in debug a debugger, but everything
is about to invest lot of energy and time. Even launching GDB is a pain. And
theres's a reason why many research live debugging using Smalltalk. When you
debug a debugger you want as much as reflection as possible and Smalltalk has
reified almost all of the internal machinery (see for example Moldable
Debugger).

------
erydo
He identified a bug in the function `evaluateIntegerExpression` which parses
an integer literal from LLDB, erroneously always parsing in base-16.

But the pull request he created
([https://github.com/facebook/chisel/pull/117](https://github.com/facebook/chisel/pull/117))
didn't fix that; instead it just replaced that function call with manually
parsing the literal in the one specific place he was having problems with.

Did I miss something there? That seems like a really weird "solution". Why not
just fix the original function?

~~~
id_ris
You're right. I put in another pull request to fix the original function, but
that's not yet been accepted.
[https://github.com/facebook/chisel/pull/122](https://github.com/facebook/chisel/pull/122)

~~~
erydo
Ah, cool, I hadn't seen that. Good work and I liked your post!

