[squeak-dev] Changeset/Concept: BytecodeDebugger.3.cs

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Tue Jan 21 16:03:23 UTC 2020

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


Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Bert Freudenberg <bert at freudenbergs.de>
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 <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> 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.
  *   ...


Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> 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!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200121/d56e3672/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 53722 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200121/d56e3672/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 57006 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200121/d56e3672/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-01-20 at 08.28.26.jpg
Type: image/jpeg
Size: 121501 bytes
Desc: Screen Shot 2020-01-20 at 08.28.26.jpg
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200121/d56e3672/attachment-0001.jpg>

More information about the Squeak-dev mailing list