<p dir="ltr">Forgot to respond to all. Sorry Jason!</p>
<div class="gmail_quote">On Jan 6, 2015 1:10 AM, "Mario Zechner" <<a href="mailto:badlogicgames@gmail.com">badlogicgames@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Jason,</p>
<p dir="ltr">thanks for the response. We temporarily 'fixed' it by disabling the eh_frame unwinder [1] in our LLDB fork. We did this after figuring out that the LLDB version shipped with XCode didn't exhibit the issue. We compared the diagnostic unwind info and found XCode's LLDB not using that unwinder plan. It's a nasty hack we'd like to get rid of.</p>
<p dir="ltr">We also found that the latest trunk of LLDB has the same issue with 32-bit x86. Here's the 32-bit version of the failing method [2]. It also contains a mid-function epilogue, bumping esp instead of rsp.</p>
<p dir="ltr">The mid-functiom epilogues are a result of translating JVM bytecode [3] straight to LLVM IR. The bytecode contains mid-function returns. I guess we could coalesce those into a single basic block just like Clang does, using a temporary to store the return value.</p>
<p dir="ltr">Thanks!<br>
Mario</p>
<p dir="ltr">[1] <a href="https://gist.github.com/badlogic/f7d65aca25270ee3b93d" target="_blank">https://gist.github.com/badlogic/f7d65aca25270ee3b93d</a><br>
[2] <a href="https://gist.github.com/badlogic/da0c7a3de6ffa3446bba" target="_blank">https://gist.github.com/badlogic/da0c7a3de6ffa3446bba</a><br>
[3] <a href="https://gist.github.com/badlogic/571fdcced98968e08499" target="_blank">https://gist.github.com/badlogic/571fdcced98968e08499</a></p>
<div class="gmail_quote">On Jan 6, 2015 12:41 AM, "Jason Molenda" <<a href="mailto:jmolenda@apple.com" target="_blank">jmolenda@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mario, sorry I missed this one over the holidays.<br>
<br>
The problem here is the '[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V' function. It has a mid-function epilogue which lldb can't handle today on x86_64. This is a common idiom on armv7/arm64 - I have experience with how to solve the problem there but I had never seen a compiler generate code like this on x86_64 so it wasn't handled there.<br>
<br>
In your example session, when you're stopped at 0x000000010014bb5f, lldb is no longer able to backtrace. Looking at the disassembly, we see that 0x10014bb5f is just past a mid-function epilogue. We'll need to update the x86_64 assembly unwinder to recognize the epilogue sequence and re-install the previous unwind state before the epilogue unwound it.<br>
<br>
0x10014bb38 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V>: pushq %rbp<br>
0x10014bb39 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+1>: movq %rsp, %rbp<br>
0x10014bb3c <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+4>: subq $0x20, %rsp<br>
0x10014bb40 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+8>: movq %rdi, -0x8(%rbp)<br>
0x10014bb44 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+12>: movq -0x10000(%rsp), %rax<br>
0x10014bb4c <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+20>: movl %esi, -0xc(%rbp)<br>
0x10014bb4f <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+23>: cmpl $0x64, -0xc(%rbp)<br>
0x10014bb53 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+27>: movq %rdi, -0x18(%rbp)<br>
0x10014bb57 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+31>: jle 0x10014bb5f ; [J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V + 39 at InvalidFrame.java:13<br>
0x10014bb59 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+33>: addq $0x20, %rsp<br>
0x10014bb5d <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+37>: popq %rbp<br>
0x10014bb5e <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+38>: retq<br>
0x10014bb5f <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+39>: movl -0xc(%rbp), %eax<br>
0x10014bb62 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+42>: addl $0x1, %eax<br>
0x10014bb65 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+45>: movl %eax, -0x10(%rbp)<br>
0x10014bb68 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+48>: movl -0x10(%rbp), %esi<br>
0x10014bb6b <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+51>: movq -0x18(%rbp), %rdi<br>
0x10014bb6f <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+55>: callq 0x10014bb38 ; [J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V at InvalidFrame.java:10<br>
0x10014bb74 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+60>: addq $0x20, %rsp<br>
0x10014bb78 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+64>: popq %rbp<br>
0x10014bb79 <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+65>: retq<br>
<br>
<br>
<br>
<br>
<br>
> On Dec 23, 2014, at 6:59 AM, Mario Zechner <<a href="mailto:badlogicgames@gmail.com" target="_blank">badlogicgames@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> i'm running into stack unwinding issues when trying to get a backtrace for a currently selected thread. You can see the output of diagnose-unwind here: <a href="https://gist.github.com/badlogic/99736e5c37f54ea08481" target="_blank">https://gist.github.com/badlogic/99736e5c37f54ea08481</a><br>
><br>
> The simple stack walking algorithm in diagnose-unwind succeeds in reconstructing the correct frames.<br>
><br>
> Any idea what I could be doing wrong or how i could fix this issue?<br>
><br>
> Thanks,<br>
> Mario<br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>
</blockquote></div>