<p dir="ltr">Sounds great! We are currently in a hot phase regarding our product. May take a bit until i get some time to test with the changes in trunk.</p>
<p dir="ltr">Thanks!<br>
Mario</p>
<div class="gmail_quote">On Jan 13, 2015 8:55 AM, "Jason Molenda" <<a href="mailto:jmolenda@apple.com">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">NB I do know about one remaining small problem with this on your example program. The eh_frame augmentation is doing the correct thing, e.g. image show-unwind says that the original eh_frame instructions were<br>
<br>
row[0]: 0: CFA=rsp +8 => rip=[rsp]<br>
row[1]: 1: CFA=rsp+16 => rbp=[rsp] rip=[rsp+8]<br>
row[2]: 4: CFA=rbp+16 => rbp=[rbp] rip=[rbp+8]<br>
<br>
<br>
& the augmented instructions identify the mid-function epilogue at offset 41, re-instate the unwind rules on offset 42, and then get the unwind rules correct for the final epilogue instruction at offset 68:<br>
<br>
row[0]: 0: CFA=rsp +8 => rip=[rsp]<br>
row[1]: 1: CFA=rsp+16 => rbp=[rsp] rip=[rsp+8]<br>
row[2]: 4: CFA=rbp+16 => rbp=[rbp] rip=[rbp+8]<br>
row[3]: 41: CFA=rsp +8 => rbp=[rsp-8] rip=[rsp]<br>
row[4]: 42: CFA=rbp+16 => rbp=[rbp] rip=[rbp+8]<br>
row[5]: 68: CFA=rsp +8 => rbp=[rsp-8] rip=[rsp]<br>
<br>
<br>
But the assembly language unwinder, which you wouldn't use here, is missing the final epilogue. It gets<br>
<br>
row[0]: 0: CFA=rsp +8 => rsp=rsp+8 rip=[rsp]<br>
row[1]: 1: CFA=rsp+16 => rbp=[rsp] rsp=rsp+16 rip=[rsp+8]<br>
row[2]: 4: CFA=rbp+16 => rbp=[rbp] rsp=rbp+16 rip=[rbp+8]<br>
row[3]: 41: CFA=rsp +8 => rsp=rsp+8 rip=[rsp]<br>
row[4]: 42: CFA=rbp+16 => rbp=[rbp] rsp=rbp+16 rip=[rbp+8]<br>
<br>
<br>
I need to track that down still but it's time to go home. For simple test programs I tried, it's doing the correct thing. But there's an off-by-one error with this particular function that I need to track down before this is complete.<br>
<br>
<br>
J<br>
<br>
<br>
> On Jan 12, 2015, at 11:41 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
><br>
> Give top of tree a try if you're still doing codegen like this. Let me know if it doesn't look correct.<br>
><br>
><br>
> Sending source/Plugins/UnwindAssembly/x86/UnwindAssembly-x86.cpp<br>
> Transmitting file data .<br>
> Committed revision 225773.<br>
><br>
><br>
><br>
>> On Jan 8, 2015, at 8:10 AM, Mario Zechner <<a href="mailto:badlogicgames@gmail.com">badlogicgames@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> sorry for taking so long. You can find a binary at<br>
>> <a href="http://libgdx.badlogicgames.com/downloads/InvalidFrameTest.zip" target="_blank">http://libgdx.badlogicgames.com/downloads/InvalidFrameTest.zip</a><br>
>><br>
>> This is a debug build for Mac OS X 64-bit. You should be able to run<br>
>> it, the README.md file has a few notes about that in it. Let me know<br>
>> if i can help any other way.<br>
>><br>
>> Thanks,<br>
>> Mario<br>
>><br>
>> On Jan 7, 2015 2:55 AM, "Jason Molenda" <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> J<br>
>>><br>
>>>> On Jan 5, 2015, at 4:34 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> J<br>
>>>><br>
>>>>> On Jan 5, 2015, at 4:10 PM, Mario Zechner <<a href="mailto:badlogicgames@gmail.com">badlogicgames@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi Jason,<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> Thanks!<br>
>>>>> Mario<br>
>>>>><br>
>>>>> [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><br>
>>>>><br>
>>>>> On Jan 6, 2015 12:41 AM, "Jason Molenda" <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
>>>>> 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">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">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>
>>>><br>
>>><br>
><br>
<br>
</blockquote></div>