On Wed Jan 21 2015 at 2:30:06 PM <jing...@apple.com> wrote: > > > On Jan 21, 2015, at 2:16 PM, Zachary Turner <ztur...@google.com> wrote: > > > > On Fri Jan 16 2015 at 1:53:00 PM Greg Clayton <gclay...@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@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
