Okay, I think I fixed this, the fix is: r253008. That passes cleanly on Linux for me, but I don't have a windows machine handy to test.
What was happening is that originally lldb had a bug where if you were stopped on a breakpoint and then the next instruction also had a breakpoint, the plan that was stepping over the breakpoint would see a stop reason of "trace" so it would think it knew why it stopped and would auto-continue, since that's what you do when you are doing "step over a breakpoint and keep going." I fixed this by having the lower layers of the process plugin correct the stop reason from trace to breakpoint when a trace ended up on another breakpoint, but apparently Linux and Windows don't have this fix. That was done a while ago, so maybe they weren't around then, I have to think about that... Anyway, the old code in ThreadPlanStepRange had a short-cut that if we only needed to go one instruction, it wouldn't do it with a breakpoint, but just stepi. I didn't preserve that in the change I made, so we got into trouble. So for now I just put that short-cut back. I wondered how this managed to cause so many Linux failures, but the OS X testsuite was clean... Jim > On Nov 12, 2015, at 4:57 PM, Zachary Turner <ztur...@google.com> wrote: > > Ahh, seems it wasn't just Windows that was affected by this. Makes me feel a > little better :) > > Posting the link to the buildbot failures here so that Jim can get full logs > if it helps. > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391 > > On Thu, Nov 12, 2015 at 4:37 PM Ying Chen <chy...@google.com> wrote: > I reverted this patch for now. > Please resubmit if you have a fix. > > Thanks, > Ying > > On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits > <lldb-commits@lists.llvm.org> wrote: > 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: > > (lldb) log enable -f <SOMEFILE> lldb step > > and then do the step, then send me that log plus the disassembly for the > function you were stepping in and the output of: > > (lldb) image dump line-table <SourceFile> > > for the source file you were stepping in. > > I should be able to see from there why we were stepping to the wrong place. > > Jim > > > On Nov 12, 2015, at 4:03 PM, Zachary Turner <ztur...@google.com> wrote: > > > > 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 > > > > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham <jing...@apple.com> wrote: > > Is the line they stepped to - instead of the expected line - always line 0? > > > > Jim > > > > > On Nov 12, 2015, at 3:52 PM, Zachary Turner <ztur...@google.com> wrote: > > > > > > Hi Jim, > > > > > > 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: > > > > > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8 > > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81 > > > 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows > > > zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, > > > GenuineIntel) > > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows > > > zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, > > > GenuineIntel) > > > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8 > > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200 > > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8 > > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200 > > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8 > > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200 > > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8 > > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8 6.2.9200 > > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) > > > > > > And here's the error I get from one of the failing tests, although I > > > don't know how much insight it provides. > > > > > > Traceback (most recent call last): > > > File > > > "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line > > > 536, in wrapper > > > return func(self, *args, **kwargs) > > > File > > > "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line > > > 2228, in dwarf_test_method > > > return attrvalue(self) > > > File > > > "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line > > > 608, in wrapper > > > func(*args, **kwargs) > > > 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 > > > self.do_step_in_past_nodebug() > > > 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 > > > self.hit_correct_line ("intermediate_return_value = > > > called_from_nodebug_actual(some_value)") > > > File > > > "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py", > > > line 57, in hit_correct_line > > > self.assertTrue (cur_line == target_line, "Stepped to line %d instead > > > of expected %d with pattern '%s'."%(cur_line, target_line, pattern)) > > > AssertionError: False is not True : Stepped to line 0 instead of expected > > > 19 with pattern 'intermediate_return_value = > > > called_from_nodebug_actual(some_value)'. > > > Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe > > > Session info generated @ Thu Nov 12 15:44:43 2015 > > > To rerun this test, issue the following command from the 'test' directory: > > > > > > If it's not obvious what the problem is, can we revert this until we > > > figure it out and then reland it? > > > > > > On Thu, Nov 12, 2015 at 2:34 PM Jim Ingham via lldb-commits > > > <lldb-commits@lists.llvm.org> wrote: > > > Author: jingham > > > Date: Thu Nov 12 16:32:09 2015 > > > New Revision: 252963 > > > > > > URL: http://llvm.org/viewvc/llvm-project?rev=252963&view=rev > > > Log: > > > Another little stepping optimization: if any of the source step commands > > > are running through a range > > > of addresses, and the range has no branches, instead of running to the > > > last instruction and > > > single-stepping over that, run to the first instruction after the end of > > > the range. If there > > > are no branches in the current range, then the bytes right after it have > > > to be in the current > > > function, and have to be instructions not data in code, so this is safe. > > > And it cuts down one > > > extra stepi per source range step. > > > > > > Incidentally, this also works around a bug in the llvm Intel assembler > > > where it treats the "rep" > > > prefix as a separate instruction from the repeated instruction. If that > > > were at the end of a > > > line range, then we would put a trap in place of the repeated > > > instruction, which is undefined > > > behavior. Current processors just ignore the repetition in this case, > > > which changes program behavior. > > > Since there would never be a line range break after the rep prefix, > > > always doing the range stepping > > > to the beginning of the new range avoids this problem. > > > > > > <rdar://problem/23461686> > > > > > > Modified: > > > lldb/trunk/source/Target/ThreadPlanStepRange.cpp > > > > > > Modified: lldb/trunk/source/Target/ThreadPlanStepRange.cpp > > > URL: > > > http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanStepRange.cpp?rev=252963&r1=252962&r2=252963&view=diff > > > ============================================================================== > > > --- lldb/trunk/source/Target/ThreadPlanStepRange.cpp (original) > > > +++ lldb/trunk/source/Target/ThreadPlanStepRange.cpp Thu Nov 12 16:32:09 > > > 2015 > > > @@ -390,12 +390,19 @@ ThreadPlanStepRange::SetNextBranchBreakp > > > if (branch_index == UINT32_MAX) > > > { > > > branch_index = instructions->GetSize() - 1; > > > + InstructionSP last_inst = > > > instructions->GetInstructionAtIndex(branch_index); > > > + size_t last_inst_size = last_inst->GetOpcode().GetByteSize(); > > > + run_to_address = last_inst->GetAddress(); > > > + run_to_address.Slide(last_inst_size); > > > + } > > > + else if (branch_index - pc_index > 1) > > > + { > > > + run_to_address = > > > instructions->GetInstructionAtIndex(branch_index)->GetAddress(); > > > } > > > > > > - if (branch_index - pc_index > 1) > > > + if (run_to_address.IsValid()) > > > { > > > const bool is_internal = true; > > > - run_to_address = > > > instructions->GetInstructionAtIndex(branch_index)->GetAddress(); > > > m_next_branch_bp_sp = > > > GetTarget().CreateBreakpoint(run_to_address, is_internal, false); > > > if (m_next_branch_bp_sp) > > > { > > > > > > > > > _______________________________________________ > > > lldb-commits mailing list > > > lldb-commits@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > > > _______________________________________________ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
