[Vm-dev] Corrupt Stack When Trying To Simulate Cogged SmallInteger>>#+
eliot.miranda at gmail.com
Fri Jan 20 21:33:28 UTC 2017
On Thu, Jan 19, 2017 at 5:30 PM, Eliot Miranda <eliot.miranda at gmail.com>
> 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
>> 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
Forgive me, I didn't look carefully enough yesterday. The method that you
need is already there. Try
This method assumes the receiver, arguments and return address are on the
Smalltalk stack and then enters the method's machine code from the
unchecked entry point. It should do exactly what you want.
If you put a fake return address on the stack then Bochs will raise an
exception as it tries to return and you'll be able to collect the result in
an exception handler.
> 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!
> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev