[Lldb-commits] [PATCH] D15407: When stepping in/over source lines, combine the addr ranges of all line table entries w/ same line num

[Jason Molenda via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added a reviewer: jingham.
jasonmolenda added a subscriber: lldb-commits.
jasonmolenda set the repository for this revision to rL LLVM.

This is a performance optimization.  

Some compilers, for instance clang, may indicate subexpressions on a source line by emitting multiple line table entries and using the column information to indicate the different expressions present in that source line.

lldb's step / next commands have a fast-stepping mode where they look at the instructions within the address range of a source line, and if there are no flow control instructions (branch, jump, call, return), it will put a breakpoint at the end of the source line address range or on the flow control instructions and continue to that breakpoint instead of instruction stepping.

When we have multiple line table entries for a source line, though, this means that we'll only fast-step through each sub-expression.  For instance, at -O0, for the input

int main (int argc, char **argv) { 
int c = argc + argc + argc + argc + argc;
return c;
}

clang may emit six line table entries for the 'int c = ...' line.  (at anything but -O0, this whole program probably turns into three assembly instructions).  The patch has a few pieces.

One: A new method on LineEntry (the object from which we get a line table entry's address range) to get the address range for this line table entry, plus any entries for the same source line that are contiguous.

Two: New overloaded methods QueueThreadPlanForStepOverRange and QueueThreadPlanForStepInRange which take a LineEntry instead of an AddressRange.  There are some callers of these methods (SBThreadPlan::QueueThreadPlanForStepInRange, SBThreadPlan::QueueThreadPlanForStepOverRange) which actually do need to use a byte range but most of the callers should pass in a LineEntry instead of resolving it down to an AddressRange.

Three: Update ThreadPlanStepRange::InRange() so when it has branched to a new part of a line table entry, it extends that one as well.  (we may have branched over a different line number's code, and our old address range may not extend as far as it should.)

There is one additional wrinkle in that the swift compiler will emit line table entries with a line number of 0 to indicate that they are compiler-generated code, not user authored code, and the debugger should strive to skip over those source lines.  If LineEntry::GetSameLineContiguousAddressRange is called with a LineEntry of 0, it will scan forward until it finds its first non-0 LineEntry, and use that line number as the line number it is trying to extend.  If it is combining LineEntries for a concrete line number and finds a LineEntry with line 0, it will add that to the address range and continue to scan for more line table entries of the same real line number.


For the new overloaded methods in Thread, QueueThreadPlanForStepOverRange, QueueThreadPlanForStepInRange, maybe it would be better to call these QueueThreadPlanForStepInLineEntry ?  The "Range" may imply that it's accepting an AddressRange, or it may just mean that we're stepping in a range of code.  I'm unable to decide on this.

Repository:
  rL LLVM

http://reviews.llvm.org/D15407

Files:
  include/lldb/Symbol/LineEntry.h
  include/lldb/Target/Thread.h
  source/API/SBThread.cpp
  source/Commands/CommandObjectThread.cpp
  source/Symbol/LineEntry.cpp
  source/Target/Thread.cpp
  source/Target/ThreadPlanStepRange.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D15407.42388.patch
Type: text/x-patch
Size: 13559 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151210/0a886a3b/attachment.bin>