jasonmolenda added a comment. Interesting. The routine is
0xf7fd9d70 <+0>: pushl %ecx 0xf7fd9d71 <+1>: pushl %edx 0xf7fd9d72 <+2>: pushl %ebp 0xf7fd9d73 <+3>: movl %esp, %ebp 0xf7fd9d75 <+5>: sysenter [...] 0xf7fd9d7e <+14>: int $0x80 --> 0xf7fd9d80 <+16>: popl %ebp 0xf7fd9d81 <+17>: popl %edx 0xf7fd9d82 <+18>: popl %ecx 0xf7fd9d83 <+19>: retl The only difference between the assembly profile v. eh_frame is that the assembly profile identifies the movl %esp, %esp instruction and says that the unwind should be done in terms of ebp. ebp and esp should be identical at this point, so it doesn't matter which one is used. But when we look at the unwind logging, ebp seems to have a value of 0 and esp seems to have a value of 0xffffd2d4. Does the sysenter / int instruction sequence mess with the contents of ebp? This routine immediately trashes the contents of ebp with the 'popl %ebp' so it's irrelevant what is stored there. In fact, I don't understand why this function saves the caller's ebp with the 'movl %esp, %ebp' insn, considering that it doesn't make use of ebp at all. Well, it is clear that lldb needs to be able to fall back to an alternate unwind scheme here - I don't know exactly what's happening during this function, but for some reason an unwind that tries to use ebp will fail. I'm also curious why lldb didn't try to use the eh_frame instructions to begin with. We generally try to do that if it looks like the instructions describe the prologue/epilogue (which this one does). I'll go look at the eh_frame augmenter and see what the rules are but maybe it has a sanity check that it wants the starting unwind rule to match the ending unwind rule, but the eh_frame unwind rules don't clear the ebp save location once ebp is restored. row[0]: 0: CFA=esp +4 => eip=[CFA-4] row[6]: 19: CFA=esp +4 => ebp=[CFA-16] eip=[CFA-4] http://reviews.llvm.org/D15046 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
