I'm wondering how it even made it to 0x1190a41. From the first bt command, that address is higher up than main. The fact that it stops there when stepping over something in main suggests that it actually got all the way through the call to printf, then returned from main then stopped at the return address of main. Does that seem like the expected behavior? <br><div class="gmail_quote">On Fri, Apr 3, 2015 at 4:04 PM Jason Molenda <<a href="mailto:jason@molenda.com">jason@molenda.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yeah, this is fallout from a stack walk algorithm that uses the rule "if we don't know any better, assume the function saved the caller's ebp on the stack and keep walking via that".<br>
<br>
> On Apr 3, 2015, at 3:43 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
<br>
> (lldb) bt<br>
> * thread #1: tid = 0x11fc, 0x011882be simple_step.exe`main(argc=1, argv=0x015e3be0) + 606 at simple_step.cpp:19, stop reason = breakpoint 1.3<br>
> * frame #0: 0x011882be simple_step.exe`main(argc=1, argv=0x015e3be0) + 606 at simple_step.cpp:19<br>
> frame #1: 0x01190a41 simple_step.exe<br>
> frame #2: 0x75107c04 kernel32.dll`<u></u>BaseThreadInitThunk + 36<br>
> frame #3: 0x7774b54f ntdll.dll`<u></u>RtlInitializeExceptionChain + 143<br>
> frame #4: 0xffffffff<br>
> (lldb) thread step-over<br>
> (lldb) Process 10848 stopped<br>
> * thread #1: tid = 0x11fc, 0x01190a41 simple_step.exe, stop reason = step over<br>
> frame #0: 0x01190a41 simple_step.exe<br>
> -> 0x1190a41: addl $0xc, %esp<br>
> 0x1190a44: movl %eax, %esi<br>
> 0x1190a46: movl %esi, -0x24(%ebp)<br>
> 0x1190a49: testl %ebx, %ebx<br>
> (lldb) bt<br>
> * thread #1: tid = 0x11fc, 0x01190a41 simple_step.exe, stop reason = step over<br>
> * frame #0: 0x01190a41 simple_step.exe<br>
> frame #1: 0x75107c04 kernel32.dll`<u></u>BaseThreadInitThunk + 36<br>
> frame #2: 0x7774b54f ntdll.dll`<u></u>RtlInitializeExceptionChain + 143<br>
> frame #3: 0xffffffff<br>
<br>
<br>
<br>
When we're stopped in 0x01190a41, lldb doesn't have any information about this function. Are we at the first instruction? Has the prologue completed? Are we in the epilogue? We have no way of knowing. We have to make a guess, and the guess, the "Architectural Default Unwind Plan", says to assume we're in the middle of the function body and that the caller's ebp has been saved and that this function sets up & uses ebp too.<br>
<br>
I think in our previous discussions you argued that lldb should *know* that it just single instruction stepped into a new function. If that knowledge could be transmitted down to the unwinder, we could use the ABI::<u></u>CreateFunctionEntryUnwindPlan unwind plan instead of the ABI::CreateDefaultUnwindPlan. The former describes how to unwind when we're sitting at the first instruction of a function. lldb doesn't have any ability to do this today, though.<br>
<br>
Anyway, because we use the "arch default unwind plan" for a function that hasn't saved the caller's ebp and copied the stack pointer into ebp itself to indicate the start of its stack frame, ebp still has main()'s stack frame value. So when the arch default unwind plan says "look at ebp to find the caller's pc address", we're essentially skipping over main().<br>
<br>
You can always spot an unwind algorithm that makes this assumption because they have the same "skip-one-frame" behavior when the 0th frame is unknown code and the unwinder skips the 1st frame. It's a common behavior in sampling type programs.<br>
<br>
One example of where the unwinder is extra smart is when the pc value is 0. When the program jumps through a null function pointer, we end up at address 0. The simplistic behavior would be to use the arch default unwind plan which would skip the 1st frame -- the one that actually jumped through the null pointer. Very unhelpful. The unwinder has code specifically to spot a pc value of 0 for the 0th frame and uses the ABI::<u></u>CreateFunctionEntryUnwindPlan unwindplan instead of the ABI::CreateDefaultUnwindPlan so we don't skip that critical frame #1.<br>
<br>
I know it's noisy but it is MUCH easier to inline the unwind logging in the console with the commands you're typing than to have it in a separate logfile. The critical unwind failure is here:<br>
<br>
> th1/fr0 initialized frame current pc is 0x1190a41 cfa is 0x114fc04 using i386 default unwind plan UnwindPlan<br>
> th1/fr0 with pc value of 0x1190a41, no symbol/function name is known.<br>
> th1/fr0 0x0000000001190a41: CFA=ebp +8 => esp=CFA+0 ebp=[CFA-8] eip=[CFA-4]<br>
><br>
> th1/fr0 CFA is 0x114fc04: Register ebp (6) contents are 0x114fbfc, offset is 8<br>
> th1/fr0 initialized frame current pc is 0x1190a41 cfa is 0x114fc04 using i386 default unwind plan UnwindPlan<br>
> th1/fr0 supplying caller's saved eip (8)'s location using i386 default unwind plan UnwindPlan<br>
> th1/fr0 supplying caller's register eip (8) from the stack, saved at CFA plus offset -4 [saved at 0x114fc00]<br>
> th1/fr1 pc = 0x75107c04<br>
> th1/fr1 with pc value of 0x75107c04, symbol name is 'BaseThreadInitThunk'<br>
<br>
<br>
We have a pc of 0x1190a41. We fall back to using the i386 default unwind plan. The unwind rule is "CFA=ebp +8 => esp=CFA+0 ebp=[CFA-8] eip=[CFA-4]". This says that we can find the caller's return address by dereferencing ebp+4 (the "Canonical Frame Address" is ebp+8 and the saved eip is at the CFA address - 4). Notice how the CFA is set in terms of ebp but your printf() hasn't set up ebp yet. That's because the unwinder is using the wrong unwind rule.<br>
<br>
<br>
A really helpful command with unwind questions is to do "image show-unwind" with -n or -a. It shows all of the different unwind rules lldb knows about for that function. I don't know if it works for a raw address like your printf() here; probably not. But you can tell from the unwind log output that lldb used the arch default unwind plan and that's the same for all functions.<br>
<br>
<br>
J</blockquote></div>