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, jing...@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 <ztur...@google.com> wrote: >> >> >> >> 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 _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
