Smalltalk › Squeak › Squeak VM

Corrupt Stack When Trying To Simulate Cogged SmallInteger>>#+

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Kruck, Bastian-2

Corrupt Stack When Trying To Simulate Cogged SmallInteger>>#+

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

Thank you so much!

Basti

170118 8+9.txt (10K) Download Attachment

ATT00001.htm (1K) Download Attachment

Clément Béra

Re: Corrupt Stack When Trying To Simulate Cogged SmallInteger>>#+

Hi Bastian,

I am not sure and I don't have much time, but usually return instructions fail in the processor simulator when returning to the interpreter code, then Cogit>>handleSimulationTrap: is responsible for simulating such returns which give back the control to the interpreter.

Is that the issue ? Else I can look further later.

Best,

On Thu, Jan 19, 2017 at 11:09 AM, Kruck, Bastian <[hidden email]> 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)
- 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.

Thank you so much!

Basti

Eliot Miranda-2

Re: Corrupt Stack When Trying To Simulate Cogged SmallInteger>>#+

In reply to this post by Kruck, Bastian-2

Hi Bastian,

welcome!

On Thu, Jan 19, 2017 at 2:09 AM, Kruck, Bastian <[hidden email]> 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

Eliot Miranda-2

Re: Corrupt Stack When Trying To Simulate Cogged SmallInteger>>#+

Hi Bastian,

On Thu, Jan 19, 2017 at 5:30 PM, Eliot Miranda <[hidden email]> wrote:

Hi Bastian,

welcome!

On Thu, Jan 19, 2017 at 2:09 AM, Kruck, Bastian <[hidden email]> 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

Forgive me, I didn't look carefully enough yesterday. The method that you need is already there. Try

executeCogMethod:fromUnlinkedSendWithReceiver:

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.

HTH

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

_,,,^..^,,,_

best, Eliot