[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,
welcome!
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