> 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.
J
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
