Debugging a Debugger

#1

Post by id_ris » Sun, Oct 25, 2015, 3:07 PM UTC

Re: Debugging a Debugger

#2

Post by userbinator » Sun, Oct 25, 2015, 4:37 PM UTC

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...

Re: Debugging a Debugger

#3

Post by id_ris » Sun, Oct 25, 2015, 5:05 PM UTC

userbinator wrote: post #2

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…

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

What is the underlying problem you're referring to?

It is admittedly a rabbit hole when you're writing code to debug code. But isn't that the whole spirit of writing tools to make your life easier and more efficient? We pile new abstraction layers atop more and more abstraction layers, and then we get computing in its impressive form as it exists today.

GDB and LLDB and any other debugger are huge software libraries for debugging, and yeah they might introduce bugs as well, but that does that mean they shouldn't be used or that they're not useful? I find it quite useful that LLDB has a scripting interface to automate debug sequences I find myself doing over and over. And since there is a scripting interface, we can find open source libraries for common debug tasks so when there is a bug, the bug is shallow due to many eyes.

Re: Debugging a Debugger

#4

Post by erydo » Sun, Oct 25, 2015, 5:05 PM UTC

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) 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?

Re: Debugging a Debugger

#5

Post by DannyBee » Sun, Oct 25, 2015, 5:31 PM UTC

id_ris wrote: post #3

userbinator wrote: post #2

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…

> IMHO when debugging software needs to be automated to the point that a library needs to be written (and itself debugged) What is the underlying problem you're referring to? It is admittedly a rabbit hole when you're writing code to debug code. But isn't that the whole spirit of writing tools to make your life easier and more efficient? We pile new abstraction layers atop more and more abstraction layers, and then w…

FWIW: I suspect the problem he's referring to is that the debugging agent layers suck in most languages.

IE given C++, or objective C, what gets described to the debugger by the compiler requires the debugger to know and do a lot to get actual values out of.

For C++, it's actually pretty good except function calls/etc require understanding the ABI. IE the debug info i get tells me "if i want to get the value of this variable, i evaluate this expression". I know the layouts of how to interpret it, etc. It's rare the expression is too complicated (though it may require piecing together registers and memory, etc, it's jsut a state machine).

For Objective C, even things like "instance variables" require the debugger understand a lot. Java has a fairly reasonable agent, etc.

Part of this is that the type systems of the debug info formats (DWARF, etc) are very simple, so even though they theoretically support things like function calls, etc, it's rarely used to provide the functionality necessary, and the debugger is left having to do it itself.

Re: Debugging a Debugger

#6

Post by id_ris » Sun, Oct 25, 2015, 5:35 PM UTC

erydo wrote: post #4

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 ) 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…

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

Re: Debugging a Debugger

#7

Post by quotemstr » Sun, Oct 25, 2015, 5:45 PM UTC

userbinator wrote: post #2

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…

> 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.

Re: Debugging a Debugger

#8

Post by quotemstr » Sun, Oct 25, 2015, 5:53 PM UTC

DannyBee wrote: post #5

id_ris wrote: post #3

Earlier quoted context omitted.

> IMHO when debugging software needs to be automated to the point that a library needs to be written (and itself debugged) What is the underlying problem you're referring to? It is admittedly a rabbit hole when you're writing code to debug code. But isn't that the whole spirit of writing tools to make your life easier and more efficient? We pile new abstraction layers atop more and more abstraction layers, and then w…

FWIW: I suspect the problem he's referring to is that the debugging agent layers suck in most languages. IE given C++, or objective C, what gets described to the debugger by the compiler requires the debugger to know and do a lot to get actual values out of. For C++, it's actually pretty good except function calls/etc require understanding the ABI. IE the debug info i get tells me "if i want to get the value of this…

It's not just the ABI: the parsing is very different too. A good C++ REPL in a debugger has to understand not only standard C++ expressions (which is a tremendous task itself), but also:

  * module-differentiated references (since foo.dll!globalThing can be different from bar.dll!globalThing) 
  * scope-differential references (each compilation unit can have its own statics)
  * CPU registers (which make perfect sense as variables in interactive debugging)
  * convenience variables
  * preprocessor macros (which we record in DWARF these days)
  * pretty-printers
  * pine number references
  * pompletion

and tons of other things. Using some kind of "agent" embedded in debugged programs as a necessary part of debugging is unacceptable, since you're frequently debugging core files and minidumps and you can't exactly put a question to a corpse. The debugger needs to understand how to do all of this itself.

Re: Debugging a Debugger

#9

Post by barrkel » Sun, Oct 25, 2015, 6:09 PM UTC

quotemstr wrote: post #8

DannyBee wrote: post #5

Earlier quoted context omitted.

FWIW: I suspect the problem he's referring to is that the debugging agent layers suck in most languages. IE given C++, or objective C, what gets described to the debugger by the compiler requires the debugger to know and do a lot to get actual values out of. For C++, it's actually pretty good except function calls/etc require understanding the ABI. IE the debug info i get tells me "if i want to get the value of this…

It's not just the ABI: the parsing is very different too. A good C++ REPL in a debugger has to understand not only standard C++ expressions (which is a tremendous task itself), but also: * module-differentiated references (since foo.dll!globalThing can be different from bar.dll!globalThing) * scope-differential references (each compilation unit can have its own statics) * CPU registers (which make perfect sense as va…

If you use a compiler's front end to parse the debugger's expressions, you can use a modification of the front end's constant expression evaluator, wherein it retrieves values and executes functions by asking the debugger.

(The Delphi IDE integrates its compiler with the debugger in this fashion.)

Re: Debugging a Debugger

#10

Post by erydo » Sun, Oct 25, 2015, 6:40 PM UTC

id_ris wrote: post #6

erydo wrote: post #4

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 ) 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…

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

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