<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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@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="gmail-">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="gmail-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="gmail-"><div><br></div></span></div></div></div></blockquote><div><br></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 <generateCaptureCStackPointers+150>: sub $0x20,%rsp<br> 0x518d0a <generateCaptureCStackPointers+154>: callq 0x506220 <zeroOpcodeIndexForNewOpcodes><br> 0x518d0f <generateCaptureCStackPointers+159>: add $0x20,%rsp<br><br></div><div>but some do not:<br><br> 0x4ed822 <generateStackPointerCapture+178>: mov 0x2071f7(%rip),%rdx # 0x6f4a20 <methodZoneBase><br> 0x4ed829 <generateStackPointerCapture+185>: mov %rdx,0x70(%rsp)<br> 0x4ed82e <generateStackPointerCapture+190>: mov 0x207203(%rip),%rdx # 0x6f4a38 <trampolineTableIndex><br> 0x4ed835 <generateStackPointerCapture+197>: mov %rdx,0x68(%rsp)<br> 0x4ed83a <generateStackPointerCapture+202>: callq 0x518c70 <generateCaptureCStackPointers><br> 0x4ed83f <generateStackPointerCapture+207>: callq *0x2b199b(%rip) # 0x79f1e0 <ceCaptureCStackPointers><br> 0x4ed845 <generateStackPointerCapture+213>: callq 0x543650 <isCFramePointerInUse><br> 0x4ed84a <generateStackPointerCapture+218>: movslq %eax,%rcx<br> 0x4ed84d <generateStackPointerCapture+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 <enterSmalltalkExecutiveImplementation+144>: xor %eax,%eax<br> 0x428312 <enterSmalltalkExecutiveImplementation+146>: mov %al,%dl<br> 0x428314 <enterSmalltalkExecutiveImplementation+148>: mov %dl,0x4d(%rsp)<br> 0x428318 <enterSmalltalkExecutiveImplementation+152>: mov 0x4d(%rsp),%al<br> 0x42831c <enterSmalltalkExecutiveImplementation+156>: mov %al,0x4c(%rsp)<br> 0x428320 <enterSmalltalkExecutiveImplementation+160>: callq *0x376eba(%rip) # 0x79f1e0 <ceCaptureCStackPointers><br> 0x428326 <enterSmalltalkExecutiveImplementation+166>: lea 0x376c33(%rip),%rcx # 0x79ef60 <reenterInterpreter><br><br>So I will have to revert last VMMaker change...<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"><span class="gmail-"><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="gmail-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="gmail-m_203044765475605969m_-6395514045624824347gmail-HOEnZb"><div class="gmail-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="gmail-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="gmail-m_203044765475605969m_-6395514045624824347gmail-HOEnZb"><div class="gmail-m_203044765475605969m_-6395514045624824347gmail-h5"><div class="gmail_extra"></div>
</div></div></blockquote></div></div></div><span class="gmail-m_203044765475605969HOEnZb"><font color="#888888"><br><br clear="all"><span class="gmail-HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="gmail-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></div><br></div></div>