Changeset/Concept: BytecodeDebugger.3.cs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Changeset/Concept: BytecodeDebugger.3.cs

Christoph Thiede

Hi all, time for some more context fun! :-)


Marcel recently mentioned to me that we could need some kind of "raw debugger" for a better experience when exploring the bytecode.

The current best work"flow" to do this was: In the open debugger, first evaluate [ThisContext method symbolic edit] in the CVI (ContextVariablesInspector) to see the bytecode. Then, while debugging, you need to evaluate [ThisContext pc] in the CVI repeatedly to check the current position and compare it with the bytecode to see what's going on. Furthermore, you could open the debug menu of the stepInto button and debug the button action to dive into the deeps of context simulation.


This changeset proposes an implementation for debugging the bytecode directly. It's still very alpha-WiP-tbd-y, but it might give you an impression of my approach.

Some screenshots (sorry, Dave!):

Comeback of the code provenance button:


Take attention to the Simulate button!



Go ahead and give me feedback! It would be nice to have an early version of this feature in Trunk in not-so-far time; I am sure this could be helpful for investigating all the context bug I reported over the latest months.

I'm excited to hear from you!


Best,

Christoph




BytecodeDebugger.3.cs (8K) Download Attachment
Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Changeset/Concept: BytecodeDebugger.3.cs

Christoph Thiede

Further ideas to improve overall bytecode tools:


  • We could reuse Marcel's recent #save*InspectorState approach to memorize which methods should be displayed as bytecode. It would be also great to extend the Debugger factory API to specify the desired contentsSymbol. CodeHolders (such as MessageSets or other debuggers) could pass their contentsSymbol if you open a new CodeHolder on them, for example by pressing Browse, Implementors, or also via debugIt. Maybe we could also make a preference for the preferred content symbol?
  • It would be great if the bytecode (i. e. CompiledCode >> #symbolic) would show real evaluable Smalltalk messages. For example, 'returnTop' has no implementors, and if you want to find out what this bytecode does, you need to either debug the stepInto button, or browse your image via #methodStringsContainingit, so I would find it much more convenient to directly write 'methodReturnTop' into the bytecode.
    A very simple approach could be the following:
InstructionPointer >> #subclassResponsibility
| sender |
sender := thisContext sender.
(self class whichCategoryIncludesSelector: sender selector) = #'instruction decoding'
ifFalse: [^ super subclassResponsibility].
self print: sender asMessage.
However, this would require a proper use of "^ self subclassResponsibility" in InstructionClient.
  • We could also use a multi-column list instead of a text pane to display the bytecodes.
  • Maybe also provide a side-by-side view of both source and bytecode with synchronized selection? This could help associating the bytecodes with the original source.
  • ...

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Montag, 20. Januar 2020 15:39 Uhr
An: Squeak Dev
Betreff: [squeak-dev] Changeset/Concept: BytecodeDebugger.3.cs
 

Hi all, time for some more context fun! :-)


Marcel recently mentioned to me that we could need some kind of "raw debugger" for a better experience when exploring the bytecode.

The current best work"flow" to do this was: In the open debugger, first evaluate [ThisContext method symbolic edit] in the CVI (ContextVariablesInspector) to see the bytecode. Then, while debugging, you need to evaluate [ThisContext pc] in the CVI repeatedly to check the current position and compare it with the bytecode to see what's going on. Furthermore, you could open the debug menu of the stepInto button and debug the button action to dive into the deeps of context simulation.


This changeset proposes an implementation for debugging the bytecode directly. It's still very alpha-WiP-tbd-y, but it might give you an impression of my approach.

Some screenshots (sorry, Dave!):

Comeback of the code provenance button:


Take attention to the Simulate button!



Go ahead and give me feedback! It would be nice to have an early version of this feature in Trunk in not-so-far time; I am sure this could be helpful for investigating all the context bug I reported over the latest months.

I'm excited to hear from you!


Best,

Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Changeset/Concept: BytecodeDebugger.3.cs

Bert Freudenberg
Nice - almost looks like my SqueakJS debugger :)

For debugging the VM I found it useful to show the current stack and context chain: 

Screen Shot 2020-01-20 at 08.28.26.jpg
 
- Bert -


On Mon, Jan 20, 2020 at 7:04 AM Thiede, Christoph <[hidden email]> wrote:

Further ideas to improve overall bytecode tools:


  • We could reuse Marcel's recent #save*InspectorState approach to memorize which methods should be displayed as bytecode. It would be also great to extend the Debugger factory API to specify the desired contentsSymbol. CodeHolders (such as MessageSets or other debuggers) could pass their contentsSymbol if you open a new CodeHolder on them, for example by pressing Browse, Implementors, or also via debugIt. Maybe we could also make a preference for the preferred content symbol?
  • It would be great if the bytecode (i. e. CompiledCode >> #symbolic) would show real evaluable Smalltalk messages. For example, 'returnTop' has no implementors, and if you want to find out what this bytecode does, you need to either debug the stepInto button, or browse your image via #methodStringsContainingit, so I would find it much more convenient to directly write 'methodReturnTop' into the bytecode.
    A very simple approach could be the following:
InstructionPointer >> #subclassResponsibility
| sender |
sender := thisContext sender.
(self class whichCategoryIncludesSelector: sender selector) = #'instruction decoding'
ifFalse: [^ super subclassResponsibility].
self print: sender asMessage.
However, this would require a proper use of "^ self subclassResponsibility" in InstructionClient.
  • We could also use a multi-column list instead of a text pane to display the bytecodes.
  • Maybe also provide a side-by-side view of both source and bytecode with synchronized selection? This could help associating the bytecodes with the original source.
  • ...

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Montag, 20. Januar 2020 15:39 Uhr
An: Squeak Dev
Betreff: [squeak-dev] Changeset/Concept: BytecodeDebugger.3.cs
 

Hi all, time for some more context fun! :-)


Marcel recently mentioned to me that we could need some kind of "raw debugger" for a better experience when exploring the bytecode.

The current best work"flow" to do this was: In the open debugger, first evaluate [ThisContext method symbolic edit] in the CVI (ContextVariablesInspector) to see the bytecode. Then, while debugging, you need to evaluate [ThisContext pc] in the CVI repeatedly to check the current position and compare it with the bytecode to see what's going on. Furthermore, you could open the debug menu of the stepInto button and debug the button action to dive into the deeps of context simulation.


This changeset proposes an implementation for debugging the bytecode directly. It's still very alpha-WiP-tbd-y, but it might give you an impression of my approach.

Some screenshots (sorry, Dave!):

Comeback of the code provenance button:


Take attention to the Simulate button!



Go ahead and give me feedback! It would be nice to have an early version of this feature in Trunk in not-so-far time; I am sure this could be helpful for investigating all the context bug I reported over the latest months.

I'm excited to hear from you!


Best,

Christoph




Reply | Threaded
Open this post in threaded view
|

Re: Changeset/Concept: BytecodeDebugger.3.cs

Christoph Thiede

Hi Bert, thanks for the impression!


This led me to even more ideas:

  • Add a flag to ContextVariablesInpector whether to show all stack items or only the named variables. If disabled, it does not need to display context top at all. If enabled, it looks more like a ContextInspector.
  • Depending on the fact whether we're debugging bytecode (#isBytecodeDebugger?), set or unset that CVI flag.
  • Also depending on #isBytecodeDebugger, show or hide the Simulate button :-)


Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Bert Freudenberg <[hidden email]>
Gesendet: Montag, 20. Januar 2020 22:40 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset/Concept: BytecodeDebugger.3.cs
 
Nice - almost looks like my SqueakJS debugger :)

For debugging the VM I found it useful to show the current stack and context chain: 

Screen Shot 2020-01-20 at 08.28.26.jpg
 
- Bert -


On Mon, Jan 20, 2020 at 7:04 AM Thiede, Christoph <[hidden email]> wrote:

Further ideas to improve overall bytecode tools:


  • We could reuse Marcel's recent #save*InspectorState approach to memorize which methods should be displayed as bytecode. It would be also great to extend the Debugger factory API to specify the desired contentsSymbol. CodeHolders (such as MessageSets or other debuggers) could pass their contentsSymbol if you open a new CodeHolder on them, for example by pressing Browse, Implementors, or also via debugIt. Maybe we could also make a preference for the preferred content symbol?
  • It would be great if the bytecode (i. e. CompiledCode >> #symbolic) would show real evaluable Smalltalk messages. For example, 'returnTop' has no implementors, and if you want to find out what this bytecode does, you need to either debug the stepInto button, or browse your image via #methodStringsContainingit, so I would find it much more convenient to directly write 'methodReturnTop' into the bytecode.
    A very simple approach could be the following:
InstructionPointer >> #subclassResponsibility
| sender |
sender := thisContext sender.
(self class whichCategoryIncludesSelector: sender selector) = #'instruction decoding'
ifFalse: [^ super subclassResponsibility].
self print: sender asMessage.
However, this would require a proper use of "^ self subclassResponsibility" in InstructionClient.
  • We could also use a multi-column list instead of a text pane to display the bytecodes.
  • Maybe also provide a side-by-side view of both source and bytecode with synchronized selection? This could help associating the bytecodes with the original source.
  • ...

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Montag, 20. Januar 2020 15:39 Uhr
An: Squeak Dev
Betreff: [squeak-dev] Changeset/Concept: BytecodeDebugger.3.cs
 

Hi all, time for some more context fun! :-)


Marcel recently mentioned to me that we could need some kind of "raw debugger" for a better experience when exploring the bytecode.

The current best work"flow" to do this was: In the open debugger, first evaluate [ThisContext method symbolic edit] in the CVI (ContextVariablesInspector) to see the bytecode. Then, while debugging, you need to evaluate [ThisContext pc] in the CVI repeatedly to check the current position and compare it with the bytecode to see what's going on. Furthermore, you could open the debug menu of the stepInto button and debug the button action to dive into the deeps of context simulation.


This changeset proposes an implementation for debugging the bytecode directly. It's still very alpha-WiP-tbd-y, but it might give you an impression of my approach.

Some screenshots (sorry, Dave!):

Comeback of the code provenance button:


Take attention to the Simulate button!



Go ahead and give me feedback! It would be nice to have an early version of this feature in Trunk in not-so-far time; I am sure this could be helpful for investigating all the context bug I reported over the latest months.

I'm excited to hear from you!


Best,

Christoph




Carpe Squeak!