[Vm-dev] Corrupt Stack When Trying To Simulate Cogged SmallInteger>>#+

Eliot Miranda eliot.miranda at gmail.com
Fri Jan 20 01:30:01 UTC 2017

Hi Bastian,


On Thu, Jan 19, 2017 at 2:09 AM, Kruck, Bastian <
Bastian.Kruck at student.hpi.de> wrote:

> Hi Folks,
> Do you have a moment to give me a hint on the following error?
> I’m currently trying to get the result of the cogged version of
> SmallInteger>>#+ by simulating it in VMMaker. So I initialise the
> simulator, lookup the method in the loaded image and finally start Bochs by
> calling simulator activateCoggedNewMethod: false.
> Now I can see the primitiveSingleStepInMemoryMinimumAddressReadWrite
> failing when trying trying to return to esp=16r11 which is my receiver. So
> it seems my stack gets corrupted at some point. So I start tracing what the
> processor is doing:
> - starts at ceEnterCogCodePopReceiverReg (pc=16r1128)

If you're using StackToRegisterMappingCogit then
ceEnterCogCodePopReceiverReg shouldn't be used to activate
SmallInteger>>#+.  StackToRegisterMappingCogit uses a register-based
calling convention (see StackToRegisterMappingCogit
class>>#callingConvention).  With the V3 memory manager 0 and 1 arg sends
are passed in registers and with Spur 0, 1 & 2 arg sends are passed in
registers.  Higher rarities are passed on the stack.  So the VM needs to
enter machine code via the callCogCodePopReceiverArg0Regs et al
enilopmarts.  What I don't understand is why this isn't happening anyway;
activateCoggedNewMethod invokes callRegisterArgCogMethod:at:receiver: to do
this.  Perhaps the simulator isn't initialized correctly?

Ah, I see.  There's an assumption that activateCoggedNewMethod will only
enter frameless methods via callRegisterArgCogMethod:at:receiver: (methods
the StackToRegisterMappingCogit optimizes to run without building a
frame).  If the method builds a frame (which SmallInteger>>#+ will if it
fails) then activateCoggedNewMethod enters after frame build.  It can
always call the Interpreter's version of the primitive if the method has a
primitive, avoiding entering machine code for primitives, since they almost
always succeed.

This doesn't work for you.  I suggest you write a variation on
activateCoggedNewMethod that uses callRegisterArgCogMethod:at:receiver: for
any method with numArgs <= numRegArgs.

- then it enters the compiled SmallInteger>>#+ (pc= 16r1462, the position
> with HasByteCodePC)
> - then it enters ceSuperSend1Args (pc=16r570)
> - and runs further up to the return (at pc=16r5aa) where it will have the
> esp=16r11
> Can you give me a hint on what’s happening here? I put the notes while
> tracing into a txt file that you can find attached. If you want to try it
> out yourself, I uploaded the image and the VM version here
> https://www.dropbox.com/sh/6sevutlcpx3of42/AAA9ScgmvK5IeLaCxE6yWJ8Ua?dl=0
> The Background: I’m currently working on my master thesis on Multi-Level
> Debugging where I’m building a debugger that is supposed to
> detect erroneous code transformations by redundantly executing the Slang,
> the running vm, the fallback code and also the JIT-compiled fallbacks.

Cool.  It's great to have another person diving into the guts of the VM.

> Thank you so much!
> Basti

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170119/e04a1a87/attachment-0001.html>

More information about the Vm-dev mailing list