Re: [Pharo-project] Some bugs
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? Marcus -- Marcus Denker -- http://marcusdenker.de
2011/9/5 Marcus Denker <marcus.denker@inria.fr>:
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?
    Marcus
OK, then I finally succeeded in decoding Marcus/Stef high level instructions into low level specifications. I translate here for those obscurantists speaking native gdb: you want step/jump instead of stepi/jumpi. But it would have been better to provide detailed explanations from the beginning for slow brained like me ;). Nonetheless, you still need to map execution machiney to source code because of initial program counter, and in case of AST-based stepping, the map must be bi-directional in order to execute multiple bytecodes sometimes required by a single instruction. Nicolas
-- Marcus Denker -- http://marcusdenker.de
OK, then I finally succeeded in decoding Marcus/Stef high level instructions into low level specifications. I translate here for those obscurantists speaking native gdb: you want step/jump instead of stepi/jumpi. But it would have been better to provide detailed explanations from the beginning for slow brained like me ;).
Nonetheless, you still need to map execution machiney to source code because of initial program counter, and in case of AST-based stepping, the map must be bi-directional in order to execute multiple bytecodes sometimes required by a single instruction.
Nicolas
yes :) we were not clear. Do not worry. Stef
On Tue, Sep 6, 2011 at 12:10 AM, Marcus Denker <marcus.denker@inria.fr> 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. Michael. -- http://gulik.pbwiki.com/
On 6 September 2011 07:41, Michael van der Gulik <mikevdg@gmail.com> wrote:
On Tue, Sep 6, 2011 at 12:10 AM, Marcus Denker <marcus.denker@inria.fr> 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.
Michael.
-- Best regards, Igor Stasenko.
On Tue, Sep 6, 2011 at 8:12 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 September 2011 07:41, Michael van der Gulik <mikevdg@gmail.com> wrote:
On Tue, Sep 6, 2011 at 12:10 AM, Marcus Denker <marcus.denker@inria.fr> 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/
participants (5)
-
Igor Stasenko -
Marcus Denker -
Michael van der Gulik -
Nicolas Cellier -
Stéphane Ducasse