On Tue, Sep 6, 2011 at 8:12 PM, Igor Stasenko <[email protected]> wrote: > On 6 September 2011 07:41, Michael van der Gulik <[email protected]> wrote: >> On Tue, Sep 6, 2011 at 12:10 AM, Marcus Denker <[email protected]> >> wrote: >>> >>> On Sep 5, 2011, at 2:06 PM, Nicolas Cellier wrote: >>>> >>>> By the way, I would find it cool to have an optional byteCode view >>>> parallel to source code view and see the execution of byte codes, and >>>> why not, a view of Context stack frames. >>>> Also, the debugger might step message by message (AST-based) rather >>>> than byteCode by byteCode, is this what you mean by wrong abstraction >>>> level ? >>>> >>> With the wrong abstraction level: Why do we care about stepping bytecodes >>> at all? Why not only have an AST interpreter based debugger? >> >> Because the debugger might be looking at bytecodes that were generated >> by something other than a Smalltalk compiler. >> > > Then AST will serve for that even better, because a single AST node > could be represented by several bytecodes, > and by using a proper AST, debugger will know for sure how to step > over single semantic element, written in your language.
The bytecodes may not have come from an AST or language. Examples: * Aspect-oriented programming, e.g. automatic logging before and after a method using bytecode injection. * Automatically generated objects, e.g. proxies that filter and send messages to another object. * Hand-crafted bytecodes (for... er... fun) * Compiler bugs - you want the debugger to actually be useful in finding incorrectly generated methods. * Commercial software, with no source code or obfuscated source code, and possibly obfuscated bytecodes if that's somehow possible. My point of view is that the debugger should be debugging bytecodes, and stepping through the original source code is a nice extra feature. This conversation is relevant to me because eventually I'll be making changes to the debugger as well. Michael. -- http://gulik.pbwiki.com/
