In practice how slow is this for stepping over very lengthy calls? It sounds like LLDB still generates a call stack at every branch point, which while certainly faster than generating one at every instruction, still seems like it has the potential to be very slow. I still wonder about an algorithm such as one that differentiates between local control flow instructions (jmp, jnz, etc) and non-local control flow instructions (call). Single step the the local control flow instructions, and put a breakpoint at the return address of the non-local control flow instructions. This requires introducing some architecture specific dependencies into the ThreadPlan, but it doesn't seem much more than those that are already in the thread plan. For example, the ThreadPlan currently has to scan forward to the next branch instruction to put the breakpoint. So this only adds the ability to differentiate between different types of branch instructions (e.g. those that transfer-and-forget, and those that transfer-and-return. Seems like this yields near zero-overhead in terms of executing the step-over. <br><div><br></div><div>As with last time, I'm probably missing something, and I'm mostly just thinking out loud :)</div><br><div class="gmail_quote">On Tue Jan 20 2015 at 12:23:28 PM Jason Molenda <<a href="mailto:jason@molenda.com">jason@molenda.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jan 20, 2015, at 4:21 AM, Hafiz Abid Qadeer <<a href="mailto:hafiz_abid@mentor.com" target="_blank">hafiz_abid@mentor.com</a>> wrote:<br>
><br>
><br>
><br>
> GDB also has range stepping thing now.<br>
> <a href="https://sourceware.org/ml/gdb-patches/2013-03/msg00450.html" target="_blank">https://sourceware.org/ml/gdb-<u></u>patches/2013-03/msg00450.html</a><br>
<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.)<br>
<br>
<br>
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.<br>
<br>
J<br>
______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>