<div dir="ltr">Here's the log. Disassembly of those two functions was posted earlier. Let me know if you need anything else:<div><br></div><div><div>ThreadPlanStepRange::SetNextBranchBreakpoint - Setting breakpoint -1 (site 2) to run to address 0x94902e</div><div>Thread::PushPlan(0x0654FBB0): "Stepping in through line with-debug.c:12.", tid = 0xb6b0.</div><div>Process::PrivateResume() m_stop_id = 2, public state: stopped private state: stopped</div><div>Thread::PushPlan(0x0654FBB0): "Single stepping past breakpoint site 1 at 0x94902b", tid = 0xb6b0.</div><div>lldb_private::ThreadPlan::WillResume Thread #1 (0x0654FBB0): tid = 0xb6b0, pc = 0x0094902b, sp = 0x00a5f8d8, fp = 0x00a5f8e8, plan = 'Step over breakpoint trap', state = stepping, stop others = 1</div><div>Process thinks the process has resumed.</div><div>Current Plan for thread 1(0654FBB0) (0xb6b0, stepping): Step over breakpoint trap being asked whether we should report run.</div><div><br></div><div>ThreadList::lldb_private::ThreadList::ShouldStop: 1 threads, 1 unsuspended threads</div><div>Thread::lldb_private::Thread::ShouldStop(0654FBB0) for tid = 0xb6b0 0xb6b0, pc = 0x000000000094902e</div><div>^^^^^^^^ Thread::ShouldStop Begin ^^^^^^^^</div><div>Plan stack initial state:</div><div> thread #1: tid = 0xb6b0:</div><div> Active plan stack:</div><div> Element 0: Base thread plan.</div><div> Element 1: Stepping in through line with-debug.c:12 using ranges:[0x0094902b-0x0094902e).</div><div> Element 2: Single stepping past breakpoint site 1 at 0x94902b</div><div><br></div><div>Plan Step over breakpoint trap explains stop, auto-continue 1.</div><div>Plan Step over breakpoint trap should stop: 0.</div><div>Completed step over breakpoint plan.</div><div>Popping plan: "Step over breakpoint trap", tid = 0xb6b0.</div><div>ThreadPlanStepInRange reached 0x0094902e.</div><div>Step range plan stepped to another range of same line: [0x0094902e-0x00949040), file = D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\with-debug.c, line = 12, column = 3</div><div>Plan Step Range stepping in should stop: 0.</div><div>Plan stack final state:</div><div> thread #1: tid = 0xb6b0:</div><div> Active plan stack:</div><div> Element 0: Base thread plan.</div><div> Element 1: Stepping in through line with-debug.c:12 using ranges: 0: [0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).</div><div> Completed Plan Stack:</div><div> Element 0: Single stepping past breakpoint site 1 at 0x94902b</div><div><br></div><div>vvvvvvvv Thread::ShouldStop End (returning 0) vvvvvvvv</div><div>ThreadList::lldb_private::ThreadList::ShouldStop overall should_stop = 0</div><div>ThreadList::lldb_private::ThreadList::ShouldReportStop 1 threads</div><div>Thread::ShouldReportStop() tid = 0xb6b0: returning vote for complete stack's back plan</div><div>ThreadPlan::ShouldReportStop() returning vote: no</div><div>ThreadList::lldb_private::ThreadList::ShouldReportStop returning no</div><div>Process::PrivateResume() m_stop_id = 3, public state: running private state: stopped</div><div>Thread::PushPlan(0x0654FBB0): "Single stepping past breakpoint site 2 at 0x94902e", tid = 0xb6b0.</div><div>lldb_private::ThreadPlan::WillResume Thread #1 (0x0654FBB0): tid = 0xb6b0, pc = 0x0094902e, sp = 0x00a5f8d8, fp = 0x00a5f8e8, plan = 'Step over breakpoint trap', state = stepping, stop others = 1</div><div>Process thinks the process has resumed.</div><div><br></div><div>ThreadList::lldb_private::ThreadList::ShouldStop: 1 threads, 1 unsuspended threads</div><div>Thread::lldb_private::Thread::ShouldStop(0654FBB0) for tid = 0xb6b0 0xb6b0, pc = 0x0000000000949031</div><div>^^^^^^^^ Thread::ShouldStop Begin ^^^^^^^^</div><div>Plan stack initial state:</div><div> thread #1: tid = 0xb6b0:</div><div> Active plan stack:</div><div> Element 0: Base thread plan.</div><div> Element 1: Stepping in through line with-debug.c:12 using ranges: 0: [0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).</div><div> Element 2: Single stepping past breakpoint site 2 at 0x94902e</div><div><br></div><div>Plan Step over breakpoint trap explains stop, auto-continue 1.</div><div>Plan Step over breakpoint trap should stop: 0.</div><div>Completed step over breakpoint plan.</div><div>Popping plan: "Step over breakpoint trap", tid = 0xb6b0.</div><div>ThreadPlanStepInRange reached 0x00949031.</div><div>Plan Step Range stepping in should stop: 0.</div><div>Plan stack final state:</div><div> thread #1: tid = 0xb6b0:</div><div> Active plan stack:</div><div> Element 0: Base thread plan.</div><div> Element 1: Stepping in through line with-debug.c:12 using ranges: 0: [0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).</div><div> Completed Plan Stack:</div><div> Element 0: Single stepping past breakpoint site 2 at 0x94902e</div><div><br></div><div>vvvvvvvv Thread::ShouldStop End (returning 0) vvvvvvvv</div><div>ThreadList::lldb_private::ThreadList::ShouldStop overall should_stop = 0</div><div>ThreadList::lldb_private::ThreadList::ShouldReportStop 1 threads</div><div>Thread::ShouldReportStop() tid = 0xb6b0: returning vote for complete stack's back plan</div><div>ThreadPlan::ShouldReportStop() returning vote: no</div><div>ThreadList::lldb_private::ThreadList::ShouldReportStop returning no</div><div>Process::PrivateResume() m_stop_id = 4, public state: running private state: stopped</div><div>lldb_private::ThreadPlan::WillResume Thread #1 (0x0654FBB0): tid = 0xb6b0, pc = 0x00949031, sp = 0x00a5f8e8, fp = 0x00a5f8e8, plan = 'Step Range stepping in', state = running, stop others = 1</div><div>Process thinks the process has resumed.</div><div>Removing next branch breakpoint: -1.</div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 12, 2015 at 4:40 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm going to try the "with patch" version again with logging enabled as you suggest. Will update soon</div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 12, 2015 at 4:36 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you can debug a failing case, and do whatever step operation got you to the wrong place, then run up to that step, and do:<br>
<br>
(lldb) log enable -f <SOMEFILE> lldb step<br>
<br>
and then do the step, then send me that log plus the disassembly for the function you were stepping in and the output of:<br>
<br>
(lldb) image dump line-table <SourceFile><br>
<br>
for the source file you were stepping in.<br>
<br>
I should be able to see from there why we were stepping to the wrong place.<br>
<br>
Jim<br>
<br>
> On Nov 12, 2015, at 4:03 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> The error messages are always different because the error message is printed by the test. I'm going to try to load up the executable for TestStepNoDebug in the debugger and get a disassembly and do the step<br>
><br>
> On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> Is the line they stepped to - instead of the expected line - always line 0?<br>
><br>
> Jim<br>
><br>
> > On Nov 12, 2015, at 3:52 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> ><br>
> > Hi Jim,<br>
> ><br>
> > This breaks about 12 tests on Windows. The patch looks simple, but this isn't really my area, is there anything I can give you to help diagnose what might be wrong? The following tests fail:<br>
> ><br>
> > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)<br>
> ><br>
> > And here's the error I get from one of the failing tests, although I don't know how much insight it provides.<br>
> ><br>
> > Traceback (most recent call last):<br>
> > File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 536, in wrapper<br>
> > return func(self, *args, **kwargs)<br>
> > File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2228, in dwarf_test_method<br>
> > return attrvalue(self)<br>
> > File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 608, in wrapper<br>
> > func(*args, **kwargs)<br>
> > File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py", line 41, in test_step_in_with_python<br>
> > self.do_step_in_past_nodebug()<br>
> > File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py", line 105, in do_step_in_past_nodebug<br>
> > self.hit_correct_line ("intermediate_return_value = called_from_nodebug_actual(some_value)")<br>
> > File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py", line 57, in hit_correct_line<br>
> > self.assertTrue (cur_line == target_line, "Stepped to line %d instead of expected %d with pattern '%s'."%(cur_line, target_line, pattern))<br>
> > AssertionError: False is not True : Stepped to line 0 instead of expected 19 with pattern 'intermediate_return_value = called_from_nodebug_actual(some_value)'.<br>
> > Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe<br>
> > Session info generated @ Thu Nov 12 15:44:43 2015<br>
> > To rerun this test, issue the following command from the 'test' directory:<br>
> ><br>
> > If it's not obvious what the problem is, can we revert this until we figure it out and then reland it?<br>
> ><br>
> > On Thu, Nov 12, 2015 at 2:34 PM Jim Ingham via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a>> wrote:<br>
> > Author: jingham<br>
> > Date: Thu Nov 12 16:32:09 2015<br>
> > New Revision: 252963<br>
> ><br>
> > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=252963&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=252963&view=rev</a><br>
> > Log:<br>
> > Another little stepping optimization: if any of the source step commands are running through a range<br>
> > of addresses, and the range has no branches, instead of running to the last instruction and<br>
> > single-stepping over that, run to the first instruction after the end of the range. If there<br>
> > are no branches in the current range, then the bytes right after it have to be in the current<br>
> > function, and have to be instructions not data in code, so this is safe. And it cuts down one<br>
> > extra stepi per source range step.<br>
> ><br>
> > Incidentally, this also works around a bug in the llvm Intel assembler where it treats the "rep"<br>
> > prefix as a separate instruction from the repeated instruction. If that were at the end of a<br>
> > line range, then we would put a trap in place of the repeated instruction, which is undefined<br>
> > behavior. Current processors just ignore the repetition in this case, which changes program behavior.<br>
> > Since there would never be a line range break after the rep prefix, always doing the range stepping<br>
> > to the beginning of the new range avoids this problem.<br>
> ><br>
> > <rdar://problem/23461686><br>
> ><br>
> > Modified:<br>
> > lldb/trunk/source/Target/ThreadPlanStepRange.cpp<br>
> ><br>
> > Modified: lldb/trunk/source/Target/ThreadPlanStepRange.cpp<br>
> > URL: <a href="http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanStepRange.cpp?rev=252963&r1=252962&r2=252963&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanStepRange.cpp?rev=252963&r1=252962&r2=252963&view=diff</a><br>
> > ==============================================================================<br>
> > --- lldb/trunk/source/Target/ThreadPlanStepRange.cpp (original)<br>
> > +++ lldb/trunk/source/Target/ThreadPlanStepRange.cpp Thu Nov 12 16:32:09 2015<br>
> > @@ -390,12 +390,19 @@ ThreadPlanStepRange::SetNextBranchBreakp<br>
> > if (branch_index == UINT32_MAX)<br>
> > {<br>
> > branch_index = instructions->GetSize() - 1;<br>
> > + InstructionSP last_inst = instructions->GetInstructionAtIndex(branch_index);<br>
> > + size_t last_inst_size = last_inst->GetOpcode().GetByteSize();<br>
> > + run_to_address = last_inst->GetAddress();<br>
> > + run_to_address.Slide(last_inst_size);<br>
> > + }<br>
> > + else if (branch_index - pc_index > 1)<br>
> > + {<br>
> > + run_to_address = instructions->GetInstructionAtIndex(branch_index)->GetAddress();<br>
> > }<br>
> ><br>
> > - if (branch_index - pc_index > 1)<br>
> > + if (run_to_address.IsValid())<br>
> > {<br>
> > const bool is_internal = true;<br>
> > - run_to_address = instructions->GetInstructionAtIndex(branch_index)->GetAddress();<br>
> > m_next_branch_bp_sp = GetTarget().CreateBreakpoint(run_to_address, is_internal, false);<br>
> > if (m_next_branch_bp_sp)<br>
> > {<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > lldb-commits mailing list<br>
> > <a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits</a><br>
><br>
<br>
</blockquote></div></div></blockquote></div>