[lldb-dev] Problem unwinding from inside of a CRT function
zturner at google.com
Wed Jan 21 14:46:40 PST 2015
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>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev