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