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

[Zachary Turner]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150121/4faca0bd/attachment.html>