Yuck :( Sounds like it's going to be a lot of work to get this working then. We're working with the Microsoft ABI, not the Itanium ABI, so I'm assuming that's why <span style="line-height:19.7999992370605px">ABISysV_x86_64::</span><u style="line-height:19.7999992370605px"></u><span style="line-height:19.7999992370605px">CreateFunction</span><span style="line-height:19.7999992370605px">EntryUnwindPlan isn't doing anything for me. Presumably I need to implement an ABIMicrosoft_x86_x64 plugin. </span><br><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">Which is unfortunate, because it seems to be needed even for basic stepping to work, like step over. Originally I was just trying to implement stepping, and that's how I ran into this issue. So that brings me to a related question. Why is step over as complicated as it is? It seems to me like step over can be implemented by disassembling 1 opcode, adding the size of the opcode to the current pc, and having the ThreadPlan::ShouldStop always return false unless the pc is equal to old_pc + size_of_opcode.</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">It currently has a lot of logic for comparing frames against each other and things like that though.</span></div><br><div class="gmail_quote">On Thu Jan 15 2015 at 4:06:23 PM Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">lldb is stopped on the first instruction of a function (at address 0x12350a1). But there's no symbol for this function -- lldb doesn't KNOW it's at the first instruction of a function. It can't profile the assembly instructions of the function to figure out how the unwind instructions should work. So lldb falls back to the "architecture default unwind plan", e.g. ABISysV_x86_64::<u></u>CreateDefaultUnwindPlan(), which assumes that the way to find the caller's eip address is to dereference ebp.<br>
<br>
Basically, you need some source of unwind info for functions. On Linux systems, this would be eh_frame instructions. On Mac OS X, there's "compact unwind" info that does the same thing. I'm sure Windows has something -- it's needed to do exception handling.<br>
<br>
If you don't have any source of unwind information, you need to have accurate function start addresses so lldb can look at the instruction stream and make up an unwind plan from those (v. UnwindAssembly-x86.cpp). But this means you need to know the start address of all functions in the file. On Mac OS X we have a special little section (LC_FUNCTION_STARTS) that encodes the length of each function in the file--so even if the function names are stripped before shipping, we can find the start address of each function easily. lldb adds these to the symbol table and makes up function names for them.<br>
<br>
If you have no compiler-generated unwind information (that lldb can parse) and you don't have start addresses for all functions in the file, things are going to work poorly.<br>
<br>
<br>
For what it's worth, when looking at unwind issues it's usually easiest to turn on the unwind logging. "log enable lldb unwind". That'll show what lldb was up to.<br>
<br>
Also, another ABI method is useful - see ABISysV_x86_64::<u></u>CreateFunctionEntryUnwindPlan(<u></u>). This is the UnwindPlan that lldb will use when it knows it is at the start of a function before any instructions have been executed.<br>
<br>
J<br>
<br>
<br>
> On Jan 15, 2015, at 3:56 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> Having some trouble unwinding when I'm broken inside of a CRT function. Another caveat is that I don't have symbols for this CRT function. So the problem could be anything from something I've done wrong on my side, to an issue when symbols aren't present, to something else. Here is the source code of this program:<br>
><br>
> #include <stdio.h><br>
><br>
> int main (void)<br>
> {<br>
> printf("This is line 1\n");<br>
> printf("This is line 2\n");<br>
> printf("This is line 3\n");<br>
> return 1;<br>
> }<br>
><br>
> Here is the disassembly of main:<br>
><br>
> (lldb) disassemble -n main -F intel<br>
> 0x1235040 <main>: push ebp<br>
> 0x1235041 <main+1>: mov ebp, esp<br>
> 0x1235043 <main+3>: sub esp, 0x14<br>
> 0x1235046 <main+6>: lea eax, [0x1230040]<br>
> 0x123504c <main+12>: mov dword ptr [ebp - 0x4], 0x0<br>
> 0x1235053 <main+19>: mov dword ptr [esp], eax<br>
> 0x1235056 <main+22>: call 0x12350a1<br>
> 0x123505b <main+27>: lea ecx, [0x1230050]<br>
> (snipped for brevity)<br>
><br>
> (Using the argument to "call" as the breakpoint address)<br>
> (lldb) break set -a 0x12350a1<br>
> Breakpoint 3: address = 0x012350a1<br>
> (lldb) run<br>
> Process 17044 launching<br>
> (lldb) Process 17044 launched: 'd:\testexe\expr_test.exe' (i386)<br>
> (lldb) Process 17044 stopped<br>
> * thread #1: tid = 0x40ec, 0x012350a1 expr_test.exe, stop reason = breakpoint 3.1<br>
> frame #0: 0x012350a1 expr_test.exe<br>
> -> 0x12350a1: pushl $0xc<br>
> 0x12350a3: pushl $0x1241000<br>
> 0x12350a8: calll 0x1235be0<br>
> 0x12350ad: xorl %edi, %edi<br>
> (lldb) disassemble -b -F intel<br>
> -> 0x12350a1: 6a 0c push 0xc<br>
> 0x12350a3: 68 00 10 24 01 push 0x1241000<br>
> 0x12350a8: e8 33 0b 00 00 call 0x1235be0<br>
> 0x12350ad: 33 ff xor edi, edi<br>
> 0x12350af: 89 7d e4 mov dword ptr [ebp - 0x1c], edi<br>
> 0x12350b2: 33 c0 xor eax, eax<br>
> 0x12350b4: 39 45 08 cmp dword ptr [ebp + 0x8], eax<br>
> 0x12350b7: 0f 95 c0 setne al<br>
> 0x12350ba: 85 c0 test eax, eax<br>
> 0x12350bc: 75 15 jne 0x12350d3<br>
><br>
> Here's my register values:<br>
> (lldb) register read<br>
> General Purpose Registers:<br>
> eax = 0x01230040<br>
> ebx = 0x00000000<br>
> ecx = 0x00000001<br>
> edx = 0x00000000<br>
> edi = 0x00000000<br>
> esi = 0x00000000<br>
> ebp = 0x00EAF920<br>
> esp = 0x00EAF908<br>
> eip = 0x012350A1<br>
> eflags = 0b0000000000000000000000100001<u></u>0110<br>
><br>
> And using the value of esp to dump the stack (sorry, I don't know how to use the -f argument to format this more nicely),<br>
><br>
> (lldb) memory read 0x00EAF908<br>
> 0x00eaf908: 5b 50 23 01 40 00 23 01 00 00 00 00 00 00 00 00 [P#.@.#.........<br>
> 0x00eaf918: 28 f9 ea 00 00 00 00 00 68 f9 ea 00 4e 52 23 01 (.......h...NR#.<br>
><br>
> So the return address is 0x0123505b. Cross-referencing this with the original disassembly of main(), it looks like this is the correct value.<br>
><br>
> So it seems like the Unwinder has all the information it needs, but yet I'm still only getting 1 frame. Any suggestions how to dig into this?<br>
<br>
</blockquote></div>