[Vm-dev] Exploring the simulator (was Re: REPL image for simulation)

Clément Bera bera.clement at gmail.com
Mon May 23 17:29:08 UTC 2016


Hi Ben,

Hopefully Chris Cunnigton was doing a tutorial video on the simulator to
help. There is one blog post from Eliot on machine code simulation for x86
in his blog (Simulating out of the Bochs or something like that).

The REPL image expects chunk format. Hence you need to write "3 + 4 !"

Your script looks nice.

I have 3 main workflows with the simulator:
1) in-image compilation: I change the way the JIT generate machine code,
use in-image compilation to check the machine code generated is as I
wanted, put halt in the JIT code and debug it as Smalltalk code while JIT
compilation. For that I use the scripts in "In-image compilation" workspace.
2) Ensuring my VM changes are correct: I start the simulator and check
there are no assertion failure / error before the display kicks in,
sometimes I try to run some code too using my VM changes by writing it in
the REPL .
3) Debugging a VM error: I start the simulator with a REPL image, then
enter the code triggering the VM crash, and try to figure out what's going
on.

In the menu, there are in order:
1) toggle Transcript (toggle between simulator and external Transcript the
output stream)
clone VM (clone the simulator, to have guinea pigs to reproduce bugs,
typically bugs hard to reproduce once you've reproduced them once or GC
bugs)
2) things related to the stacks.
'printcallStack' is the main one which prints the current stack.
'print ext head frame' prints the current stack frame, very useful too.
These 2 are the most useful. Other entries are situational.
3) 'printOop:' expects parameter in hex, printing an oop, if non immediate
the header and all the fields.
disassemble entries are very useful to disassemble where the VM has crashed
or disassemble a method that looks suspicious based on its address.
4) inspect objectMemory or interpreter to look into the variables value, if
crash in GC or interpreter
Or run the leak checked to look for memory leaks.
Or inspect cogit if a bug happened during JIT compilation
Or inspect the method zone, typically useful to analyze it
5) print cog methods and trampoline (similar to disassemble, used for
debugging the machine code)
All the *break* things stop execution on a specific selector / pc / block /
..
If single stepping is enabled (you need to do that only on small portion of
code, the machine code gets dog slow), then you can report recent
instructions to see the register state at each machine instructions, etc).

To get warmed-up:
1) Inspect the object memory, then look for the first class table page
instance variable. It's an oop referencing an array, try in the simulator
to "printOop:" the address of the first class table page that you found. It
should print it in the Transcript, the first entries are immediate, in
Spur32 SmallInteger/Character/SmallInteger.
2) print the active stack, look for the method's address. Try to print it
as an oop, and if it tells you "address in the machine code zone", print
the cog method and its machine code instead.

Have fun.

I'll try to answer further questions as I like to see people hacking the
VM, but I am quite busy :-)



On Mon, May 23, 2016 at 6:06 PM, Ben Coman <btc at openinworld.com> wrote:

>
> On Mon, May 23, 2016 at 3:14 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> >> On May 22, 2016, at 9:43 AM, Ben Coman <btc at openinworld.com> wrote:
> >>
> >>> On Sat, May 21, 2016 at 4:44 AM, Clément Bera <bera.clement at gmail.com>
> wrote:
> >>>
> >>>> On Fri, May 20, 2016 at 7:29 PM, Ben Coman <btc at openinworld.com>
> wrote:
> >>>>
> >>>> On Fri, May 20, 2016 at 8:44 PM, Clément Bera <bera.clement at gmail.com>
> wrote:
> >>>
> >>> Normally if you build a cog development image:
> >>> $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image
> >>> $ cd ./image
> >>> $ ./buildsqueaktrunkvmmakerimage.sh
> >>>
> >>> You have multiple scripts available with comments to run the simulator
> that work out of the box. It should take a couple minutes to get it
> working. Then the easiest is to simulate a REPL image to easily debug what
> you want.
> >>
> >> Hi Clement,
> >>
> >> Could you point me to such a REPL image?
> >>
> >> cheers -ben
>
> >
> > Hi Ben,
> >
> >     see buildspurreaderimage.sh, or it may be
> buildspurtrunkreaderimage.sh, in the image directory.
>
> Thanks Eliot.  I now have an "Input please" window.  I presume I
> should type Smalltalk expressions in there.  For a while it was
> confusing that I could see no effect entering...
>    3+4
> or...
>   Transcript show:'hello'
>
> Nothing moving in the Simulator's trace pane, nor the Transcript
> within the simulation, nor the host's Transcript, but after selecting
> menu item "print instructions each instruction" I see 3+4 produce a
> stream of instructions in the host transcript.
>
> With such a long list of menu items, I expect now I'll bug everyone to
> discover what they all are.  I'll use this thread to log random things
> I discover for posterity for myself and other VM newcomers.  There
> doesn't seem a lot of info out there on the simulator and maybe some
> will spark some short comments, but I don't expect feedback on
> everything.
>
> But first, what are a few important menu or workflow items a VM
> newcomer working with the REPL image would find useful?
>
> cheers -ben
>
> P.S. After running ./buildspurtrunkreaderimage.sh
> this is the code I ran in the host image...
> | cos |
> cos := CogVMSimulator newWithOptions: #(Cogit
> StackToRegisterMappingCogit "SimpleStackBasedCogit"
> ObjectMemory Spur32BitCoMemoryManager
> "ISA ARMv5" "ISA IA32").
> "cos initializeThreadSupport."
> cos desiredNumStackPages: 8.
> cos openOn: 'spurreader.image'.
> cos openAsMorph; run
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160523/ef9efacf/attachment.htm


More information about the Vm-dev mailing list