<div dir="ltr"><br><br><div class="gmail_quote">On Wed Jan 21 2015 at 2:30:06 PM <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jan 21, 2015, at 2:16 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> On Fri Jan 16 2015 at 1:53:00 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
><br>
> Also, did you get my comment about improving functions bounds in the COFF parser? If you can do this, you won't really need to do any of the unwinding stuff because the assembly unwinder will take care of it, you just need to get good function bounds for everything using any means necessary in the ObjectFileCOFF parser by making all the symbols you can. You also need to identify what parts are trampolines. For example a call to printf usually goes through a PLT entry. These are often in one place in your binary and often there are not symbols in the symbol table for these. Identifying the symbols with a name like "printf" and also making the symbol a eSymbolTypeTrampoline will allow us to not set a breakpoint on your "printf" trampoline when you say "b printf" on the command line, and it will also give function bounds to these small trampoline code sections so we can step and unwind through them.<br>
><br>
><br>
>  Regarding the function bounds, I thought about this some, and I'm not sure if this is going to be possible.  Consider a system library, like the CRT, being linked against with no symbol information.  Where are the function bounds going to coem from?  There's nothing in the symbol table of the COFF file, and there's no debug info.  And since we're talking about an x86 binary, unwind info is not part of the ABI.  There's just a huge block of code in the code section.  Even if we do have symbols (which is how we would determine function bounds for code we have no control over), we will only have "public symbols" released by Microsoft.  Public symbols do not consist of information about every function, and practically any non-trivial call is going to at some point transfer control to one of the private functions that have no symbol information.<br>
<br>
For generic backtracing, that's going to be a problem.  For instance, if you want to interrupt & do a backtrace at some random point, you may get a frame wrong.  If the MS unwind library gets this right, by all means use that as a host function.  If they get that right, I'd be interested to see how they do that (though we probably will never know...)  After all, just doing "find the instruction just before from the current pc" is not entirely trivial on x86...<br></blockquote><div> </div><div>It's funny you should mention that, because one of my favorite commands on Windows is "disassemble backwards".  I actually wanted to implement this in LLDB eventually.  But I haven't spent time to figure out how Windbg handles reverse disassembling with no symbol information, or if it works at all.</div></div></div>