One important thing to get right before proceeding is getting the correct address bounds of all functions so that the disassembly unwinder can do its job. You said you are stopped at a function, but don't know the function bounds. You will want to modify your object file reader (COFF?) to create a viable symbol table that can be used. On MacOSX we use the actual symbol table from the object file and supplement it with all sorts of goodies: 1 - LC_FUNCTION_STARTS load command which tells us all function bounds even if their symbols have been stripped 2 - the PLT entries are made into symbols 3 - more data from the __LINKEDIT is used to create other symbols
Can you modify your COFF plug-in to get the symbols bounds for every function somehow? Then we can rely on the unwind plan that manually disassembles the functions and makes its own unwind info. Greg > On Jan 15, 2015, at 5:01 PM, Zachary Turner <ztur...@google.com> wrote: > > Btw, I'm still a little uncomfortable that not having unwind/ symbol info at > any point no matter how deep in a function call chain, has the possibility to > mess up a step over. In my original example, i had symbols for main but not > printf. Is that not sufficient to step over a call to printf? It should be > able to know from that a) the bounds of main(), b) the pc corresponding to > the next line of source after printf, and c) the value of esp. Aren't those 3 > pieces of information enough to step over any line of source, regardless of > whether you have unwind information for the code inside the function you're > stepping over? > On Thu, Jan 15, 2015 at 4:36 PM <jing...@apple.com> wrote: > > > On Jan 15, 2015, at 4:18 PM, Zachary Turner <ztur...@google.com> wrote: > > > > Which is unfortunate, because it seems to be needed even for basic stepping > > to work, like step over. Originally I was just trying to implement > > stepping, and that's how I ran into this issue. So that brings me to a > > related question. Why is step over as complicated as it is? It seems to > > me like step over can be implemented by disassembling 1 opcode, adding the > > size of the opcode to the current pc, and having the ThreadPlan::ShouldStop > > always return false unless the pc is equal to old_pc + size_of_opcode. > > > > You are describing "thread step-inst". That should pretty much always work > regardless of unwinder, etc. > > Source step over, as Jason said, is much more complicated. > > Jim > _______________________________________________ > 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
