jasonmolenda added a comment.

Thanks Jim, I'll fix those issues.

With line 0's, I think there are three scenarios of interest (none of this 
contradicts what you wrote, I'm just spelling it out for myself):

1 We are stepping over a source line and we find a line 0.  We want to include 
that line 0.  If that same source line # appears after line 0, continue to 
extend our stepping range.

2 We are somehow starting on a line 0 (which lldb will try to avoid - but an 
asynchronous interrupt may have put us here).  I think the debugger will show 
the first non-zero line number as the "currently executing" source line in this 
case.  So a 'next' should consume the line 0 that we're on, plus the next 
source line that we encounter.

3 We're stepping a source line "n", we branch over a different source line and 
find ourselves in a line 0.  In this case we want to consume the 0, and if we 
find the next non-zero line number is "n", continue to expand the range.  If 
it's non-"n", then we need to stop expanding the range.

#2 and #3 are trickily similar; I implemented #2 (if we start with a line 0, 
adopt the first non-zero line num we encounter) in this patch.  #3 won't 
actually happen because ThreadPlanStepRange::InRange() (which handles the case 
where we've finished stepping through a range of addresses and we look at the 
new pc to see if it is still a part of the same line -- so realistically, when 
we've branched over another source line now that we extend line ranges) treats 
"the new pc is the same line number as the original line number" and "the new 
pc is line number 0" separately - and if the new pc is line 0, it replaces the 
line number with the original line number.  (this isn't a change by me - that 
was the existing code behavior)

It's a subtle behavior and that's probably not good to rely on it happening to 
be written correctly - I almost tried to combine the "line 0" and "non-line 0" 
sections of ThreadPlanStepRange::InRange when  I was writing the patch and it 
took me a minute to think through the implications of doing that.


Repository:
  rL LLVM

http://reviews.llvm.org/D15407



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to