When lldb is instruction stepping (or fast-stepping / instruction stepping) over a source line, and it instruction steps into a function call, and the function is not "interesting" to the user, lldb sets a breakpoint on the return address and continues the process until that breakpoint is hit on the current thread.
lldb has a fast-stepping approach to avoid stopping at every instruction in a source line range - it only stops on instructions that can branch / return / call functions.
So we have one extra stop when nexting over a function call. We step into the uninteresting-function, put a breakpoint on the return address, continue, hit the breakpoint on the return address and then we fast-step to the next branch instruction. That was four extra gdb-remote protocol packets for every function call in a source line.
This patch advances the stop breakpoint to the first branching instruction after we return, or to the end of the source line.
It passes the testsuite. I'll be doing more by-hand testing in the following week or two when I have time, but it's a straightforward change, it shouldn't cause problems unless I've missed something. I added the new Process::AdvanceAddressToNextBranchInstruction() method but I'm only calling it from ThreadPlanStepOut::ThreadPlanStepOut. I thought I'd be able to unify this new function with the code in ThreadPlanStepRange::SetNextBranchBreakpoint but I don't think the few lines I could remove from ThreadPlanStepRange::SetNextBranchBreakpoint would be worth the change. Jim might disagree with that.
The one point where this would be incorrect is a command like "finish" which displays the return value after the function exits. On an architecture where the return values are passed in volatile registers (x86, arm), that register may be overwritten after the function return so we must stop on the return address.