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
