Hi, sorry for taking so long. You can find a binary at http://libgdx.badlogicgames.com/downloads/InvalidFrameTest.zip
This is a debug build for Mac OS X 64-bit. You should be able to run it, the README.md file has a few notes about that in it. Let me know if i can help any other way. Thanks, Mario On Jan 7, 2015 2:55 AM, "Jason Molenda" <jmole...@apple.com> wrote: > > Can you send me a binary with one of these mid-function epilogues in the > middle? I'm not going to run it. (I mean, if you want to make a self > contained binary that I *could* run, that'd be awesome but I can test it by > static inspection by using 'image show-unwind' after loading the binary into > an x86-64 debug session) it'll be easier to add support for mid-function > epilogues if I have an example of one without having to write it myself. > > J > > > On Jan 5, 2015, at 4:34 PM, Jason Molenda <jmole...@apple.com> wrote: > > > > I should fix the x86 assembly unwinder, it's something I knew would fail > > eventually when lldb was used on a significantly different code generation > > style. It's not terribly difficult - assembly profiler code needs to save > > the unwind state once the prologue has finished. When it detects the start > > of the epilogue instruction sequence, it preserves the unwind state until > > the epilogue has finished and then re-installs it. > > > > If you can change your codegen to have a single return for i386/x86_64, > > that would definitely work. But this is a limitation in the x86 unwinder > > right now - that's where the real fix should be done. > > > > J > > > >> On Jan 5, 2015, at 4:10 PM, 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
