Forgot to respond to all. Sorry Jason! On Jan 6, 2015 1:10 AM, "Mario Zechner" <badlogicga...@gmail.com> wrote:
> Hi Jason, > > 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. > > 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. > > 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. > > Thanks! > Mario > > [1] https://gist.github.com/badlogic/f7d65aca25270ee3b93d > [2] https://gist.github.com/badlogic/da0c7a3de6ffa3446bba > [3] https://gist.github.com/badlogic/571fdcced98968e08499 > On Jan 6, 2015 12:41 AM, "Jason Molenda" <jmole...@apple.com> wrote: > >> Hi Mario, sorry I missed this one over the holidays. >> >> 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. >> >> 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. >> >> 0x10014bb38 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V>: pushq >> %rbp >> 0x10014bb39 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+1>: movq >> %rsp, %rbp >> 0x10014bb3c >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+4>: subq >> $0x20, %rsp >> 0x10014bb40 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+8>: movq >> %rdi, -0x8(%rbp) >> 0x10014bb44 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+12>: movq >> -0x10000(%rsp), %rax >> 0x10014bb4c >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+20>: movl >> %esi, -0xc(%rbp) >> 0x10014bb4f >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+23>: cmpl >> $0x64, -0xc(%rbp) >> 0x10014bb53 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+27>: movq >> %rdi, -0x18(%rbp) >> 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 >> 0x10014bb59 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+33>: addq >> $0x20, %rsp >> 0x10014bb5d >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+37>: popq >> %rbp >> 0x10014bb5e >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+38>: retq >> 0x10014bb5f >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+39>: movl >> -0xc(%rbp), %eax >> 0x10014bb62 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+42>: addl >> $0x1, %eax >> 0x10014bb65 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+45>: movl >> %eax, -0x10(%rbp) >> 0x10014bb68 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+48>: movl >> -0x10(%rbp), %esi >> 0x10014bb6b >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+51>: movq >> -0x18(%rbp), %rdi >> 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 >> 0x10014bb74 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+60>: addq >> $0x20, %rsp >> 0x10014bb78 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+64>: popq >> %rbp >> 0x10014bb79 >> <[J]com.robovm.debug.server.apps.InvalidFrame.testRecursion(I)V+65>: retq >> >> >> >> >> >> > On Dec 23, 2014, at 6:59 AM, Mario Zechner <badlogicga...@gmail.com> >> wrote: >> > >> > Hi, >> > >> > 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: https://gist.github.com/badlogic/99736e5c37f54ea08481 >> > >> > The simple stack walking algorithm in diagnose-unwind succeeds in >> reconstructing the correct frames. >> > >> > Any idea what I could be doing wrong or how i could fix this issue? >> > >> > Thanks, >> > Mario >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >>
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
