<div dir="ltr">Hi Nicolas,<div><br></div><div>    as far as I can see in <a href="https://msdn.microsoft.com/en-us/library/ms235286.aspx">https://msdn.microsoft.com/en-us/library/ms235286.aspx</a> we do not simulate the shadow space convention so any bugs will not show up in the simulator.  I will modify the simulator to smash the shadow space on the stack and see how far we get.  That should break things and hence make it possible to debug and fix the issue.  The convention is pretty simple:</div><div><br></div><div>"The caller is responsible for allocating space for parameters to the callee, and must always allocate sufficient space to store four register parameters, even if the callee doesn’t take that many parameters. This simplifies support for unprototyped C-language functions, and vararg C/C++ functions. For vararg or unprototyped functions, any floating point values must be duplicated in the corresponding general-purpose register. Any parameters beyond the first four must be stored on the stack, above the shadow store for the first four, prior to the call. Vararg function details can be found in Varargs. Unprototyped function information is detailed in Unprototyped Functions."</div><div><br></div><div>There may be places where we simply call directly into the run-time and forget to make the shadow space available.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 5:55 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2017-05-26 9:24 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@<wbr>gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_6681545308148091457gmail-">2017-05-25 17:49 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Nicolas,<div class="gmail_extra"><br><div><div class="m_6681545308148091457gmail-h5"><div class="gmail_quote"><span>On Wed, May 24, 2017 at 11:28 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Great, you reproduced exact same behavior.<br></div>The problem I have is effectively where to put the breakpoint.<br></div><div>I think we can believe the output of (gdb) call printCallStack()<br></div></div></div></div></div></div></div></div></blockquote><div><br></div></span><div>here's one issue; the computation to see if the frame pointer is in use fails.  I'm executing this at the compilation break point for <span style="color:rgb(0,0,0);font-size:12.8px">FilePath class>pathName:isEncoded:</span></div><div><br></div><div>(gdb) print /x CStackPointer</div><div>$7 = 0xef91d0</div><div>(gdb) print /x CFramePointer</div><div>$8 = 0x0</div><div>(gdb) print cFramePointerInUse</div><div>$9 = 0</div><div>(gdb) info registers</div><div>rax            0x68588f 6838415</div><div>rbx            0xffffffff       4294967295</div><div>rcx            0x68588f 6838415</div><div>rdx            0xabababab003a643a       -6076574521274768326</div><div>rsi            0xfde9   65001</div><div>rdi            0x0      0</div><div>rbp            0xef5db0 0xef5db0</div><div>rsp            0xef5c50 0xef5c50</div><div>r8             0x0      0</div><div>r9             0xfffffffffbefbc48       -68174776</div><div>r10            0xe36e626d44726839       -2058599758222432199</div><div>r11            0x8101010101010100       -9151031864016699136</div><div>r12            0xffffffff       4294967295</div><div>r13            0x20     32</div><div>r14            0x7ffc202018f0   140720847460592</div><div>r15            0xf2faf0 15923952</div><div>rip            0x4015d9 0x4015d9 <warning+9></div><div>eflags         0x206    [ PF IF ]</div><div>cs             0x33     51</div><div>ss             0x2b     43</div><div>ds             0x2b     43</div><div>es             0x2b     43</div><div>fs             0x53     83</div><div>gs             0x2b     43</div><div>(gdb)</div><span><div> </div></span></div></div></div></div></div></blockquote><div><br></div><div>So ceCaptureStackPointers() must get the value of SP and eventually FP in the caller.<br></div><div>For getting caller SP, it must unstack the push RBX, and the return address.<br><br></div><div>But on Win64 ABI it's not enough, because stack space is reserved for the 4 register arguments even if there is less than 4...<br></div><div>So we must add 32 bytes more to callee SP in order to retrieve caller SP...<br></div><span class="m_6681545308148091457gmail-"><div><br></div></span></div></div></div></blockquote><div><br></div></div></div><div>Hmmm wrong guess from my side.<br></div><div>Some calls do explicitely reserve the stack space for saving the 4 register parameters like:<br><br>   0x518d06 <<wbr>generateCaptureCStackPointers+<wbr>150>:        sub    $0x20,%rsp<br>   0x518d0a <<wbr>generateCaptureCStackPointers+<wbr>154>:        callq  0x506220 <zeroOpcodeIndexForNewOpcodes><br>   0x518d0f <<wbr>generateCaptureCStackPointers+<wbr>159>:        add    $0x20,%rsp<br><br></div><div>but some do not:<br><br>   0x4ed822 <generateStackPointerCapture+<wbr>178>:  mov    0x2071f7(%rip),%rdx        # 0x6f4a20 <methodZoneBase><br>   0x4ed829 <generateStackPointerCapture+<wbr>185>:  mov    %rdx,0x70(%rsp)<br>   0x4ed82e <generateStackPointerCapture+<wbr>190>:  mov    0x207203(%rip),%rdx        # 0x6f4a38 <trampolineTableIndex><br>   0x4ed835 <generateStackPointerCapture+<wbr>197>:  mov    %rdx,0x68(%rsp)<br>   0x4ed83a <generateStackPointerCapture+<wbr>202>:  callq  0x518c70 <<wbr>generateCaptureCStackPointers><br>   0x4ed83f <generateStackPointerCapture+<wbr>207>:  callq  *0x2b199b(%rip)        # 0x79f1e0 <ceCaptureCStackPointers><br>   0x4ed845 <generateStackPointerCapture+<wbr>213>:  callq  0x543650 <isCFramePointerInUse><br>   0x4ed84a <generateStackPointerCapture+<wbr>218>:  movslq %eax,%rcx<br>   0x4ed84d <generateStackPointerCapture+<wbr>221>:  mov    %rcx,0x2b1844(%rip)        # 0x79f098 <cFramePointerInUse><br><br></div><div>If I put a breakpoint:<br></div><div>(gdb) break generateStackPointerCapture<br><br></div><div>then I see that the frame pointer is not in use in this function:<br><br>(gdb) print $rbp<br>$6 = (void *) 0x0<br><br>then:<br><br>(gdb) print $rsp<br>$7 = (void *) 0xf2f250<br><br></div><div>if I step over ceCaptureCStackPointers()<br>=> 0x4e00010:   push   %rbx<br>   0x4e00011:   mov    $0x6dc018,%rbx<br>   0x4e00018:   mov    %rbp,0xc3158(%rbx)<br>   0x4e0001f:   mov    %rsp,%rax<br>   0x4e00022:   add    $0x30,%rax<br>   0x4e00026:   mov    %rax,0xc3140(%rbx)<br>   0x4e0002d:   pop    %rbx<br><br></div><div>i find:<br><br>(gdb) print CFramePointer<br>$10 = (void *) 0x0<br></div><div>(gdb) print CStackPointer<br>$9 = (void *) 0xf2f270<br><br></div><div>0x20 too much...<br><br>The other sender of ceCaptureCStackPointers does not use sub    $0x20,%rsp either<br><br>   0x428310 <<wbr>enterSmalltalkExecutiveImpleme<wbr>ntation+144>:        xor    %eax,%eax<br>   0x428312 <<wbr>enterSmalltalkExecutiveImpleme<wbr>ntation+146>:        mov    %al,%dl<br>   0x428314 <<wbr>enterSmalltalkExecutiveImpleme<wbr>ntation+148>:        mov    %dl,0x4d(%rsp)<br>   0x428318 <<wbr>enterSmalltalkExecutiveImpleme<wbr>ntation+152>:        mov    0x4d(%rsp),%al<br>   0x42831c <<wbr>enterSmalltalkExecutiveImpleme<wbr>ntation+156>:        mov    %al,0x4c(%rsp)<br>   0x428320 <<wbr>enterSmalltalkExecutiveImpleme<wbr>ntation+160>:        callq  *0x376eba(%rip)        # 0x79f1e0 <ceCaptureCStackPointers><br>   0x428326 <<wbr>enterSmalltalkExecutiveImpleme<wbr>ntation+166>:        lea    0x376c33(%rip),%rcx        # 0x79ef60 <reenterInterpreter><br><br>So I will have to revert last VMMaker change...<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_6681545308148091457gmail-"><div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div></div><div><br></div>I've tried other means:<br></div>- analyze direct usage of registers RCX & co from VMMaker<br>  if ever it could conflicts with WIN64 logical register assignment<br></div><div>  But I did not find anything<br></div>- compile with MSVC 2017<br></div><div>  if ever the compiler could spit different warnings and give a clue<br></div>  alas it fails very early in readImageFromFileHeapSizeStart<wbr>ingAt (during checkAssumedCompactClasses)<br></div> the failure is incomprehensible, because the debugger shows identical contents if I print:<br><br>        *((sqInt *)(classTableFirstPage+8+(51<<<wbr>3)))    140697255509608    __int64<br>        *((sqInt *)(specialObjectsOop+8+(7<<3))<wbr>)    140697255509608    __int64<br><br></div>nonetheless, the debugger enters into the if and execute<br>        invalidCompactClassError("Arra<wbr>y");<br><br></div>I'll have to debug it at assembler level, but it's driving me away from the original problem...<br></div></blockquote><div><br></div></span><div>Hmmm.  I doubt this is a problem because the assert and debug VMs would print a warning if this were wrong and they seem to be doing fine (I'm using the clang build).</div><div><div class="m_6681545308148091457gmail-m_203044765475605969h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><div class="m_6681545308148091457gmail-m_203044765475605969m_-6395514045624824347gmail-HOEnZb"><div class="m_6681545308148091457gmail-m_203044765475605969m_-6395514045624824347gmail-h5"><div class="gmail_extra"><br></div></div></div></blockquote></div></div></div></div></div></blockquote><div><br></div></span><div>This is a MSVC code generation bug.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_6681545308148091457gmail-m_203044765475605969h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_6681545308148091457gmail-m_203044765475605969m_-6395514045624824347gmail-HOEnZb"><div class="m_6681545308148091457gmail-m_203044765475605969m_-6395514045624824347gmail-h5"><div class="gmail_extra"></div>
</div></div></blockquote></div></div></div><span class="m_6681545308148091457gmail-m_203044765475605969HOEnZb"><font color="#888888"><br><br clear="all"><span class="m_6681545308148091457gmail-HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_6681545308148091457gmail-m_203044765475605969m_-6395514045624824347gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</font></span></font></span></div></div>
</blockquote></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div>