On 20/01/15 20:15:15, Jason Molenda wrote: > > > On Jan 20, 2015, at 4:21 AM, Hafiz Abid Qadeer > <hafiz_a...@mentor.com> wrote: > > > > > > > > GDB also has range stepping thing now. > > https://sourceware.org/ml/gdb-patches/2013-03/msg00450.html > > > > Jim points out that this is a different approach than lldb took -- > it's pushing some limited amount of single instruction stepping down > into the remote stub. > > The cost of single instruction stepping can be broken down into (1) > time to stop the inferior process, (2) time to communicate inferior > state between stub and debugger, and (3) time for the debugger decide > whether to resume the process or not. > > The gdb approach reduces 2 & 3. lldb's approach is addressing all of > 1-3. A single source line may have many function calls embedded > within it -- printf("%d\n", f(g(x))); -- so lldb will still be need > to > stop the inferior 4 more times than gdb for this sequence (stop at > the > point of the call instruction, then single instruction step into the > call -- whereas with gdb's approach the stub will single instruction > step into the call and then report back to gdb). > > In lldb we've put a lot of time in optimizing #2. Besides getting > rid > of the "acks" in the gdb-remote protocol by default (needed for an > unreliable transport medium, like a raw serial connection to a target > board), we looked at what pieces of information lldb needs to decide > whether to keep stepping or stop. It needs to know the stop reason, > it needs to know the pc, it needs the stack pointer, and it probably > needs the frame pointer. So in the "T" packet which the stub sends > to > indicate that the inferior has stopped, we have a list of "expedited > registers" - register values that the stub provides without being > asked. > > The result is that every time lldb needs to step a single instruction > within a function bounds, there are two packets sent: The "T05" > packet indicating the inferior stopped, and lldb sending back another > "vCont;s" packet saying to instruction step again, if appropriate. > The overhead of #2 has been dramatically reduced by this approach. > (think about a scenario where there are no expedited registers in the > T packet - the debugger is going to need to ask for each of these > registers individually, or get all registers via the g packet, and > it's going to be really slow.) > > > The approach Jim did with lldb does assume that you have a > disassembler with annotations regarding whether an instruction can > affect flow control - branches, calls, jumps, etc. The llvm > disassembler includes these annotations. Last time I looked at the > disassembler gdb is using, it doesn't include this kind of > information > about instructions.
Jim & Jason, Thanks for explaining this in details. I also like the ability provided by functions like QueueThreadPlanForStepOverRange. You can experiment by providing your own step plan if you want in your process plugin. Regards, Abid _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
