[lldb-dev] Problem unwinding from inside of a CRT function

[Jason Molenda]

There was an old framework on Mac OS X that would find function bounds in an unknown code base (back before we had function start addresses) -- on x86 it would do as Jim suggests, scan backwards, look for a typical function prologue byte sequence (push rbp; mov rsp, rbp) and then disassemble forward again to see if it got to the same address.

Any backwards scanning algorithm is surely going to be looking for a commonly-occuring sequence of instructions.  The function prologue is as good as any, I wouldn't be surprised if the MS disassembler did the same thing.


> On Jan 21, 2015, at 3:02 PM, jingham at apple.com wrote:
> 
> The simple way to do this is to go to the first symbol north of your current address, disassemble forward till you get to the current PC, then display the last N instructions in that disassembly (maybe caching the disassembly for extra credit.)
> 
> There are probably other tricky ways to do this if you know lots about x86, but that's not my area of expertise.
> 
> Jim
> 
> 
>> On Jan 21, 2015, at 2:46 PM, Zachary Turner <zturner at google.com> wrote:
>> 
>> 
>> 
>> On Wed Jan 21 2015 at 2:30:06 PM <jingham at apple.com> wrote:
>> 
>>> On Jan 21, 2015, at 2:16 PM, Zachary Turner <zturner at google.com> wrote:
>>> 
>>> On Fri Jan 16 2015 at 1:53:00 PM Greg Clayton <gclayton at apple.com> wrote:
>>> 
>>> 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.
>>> 
>>> 
>>> 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.
>> 
>> 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...
>> 
>> 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.
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev