I'm going to try the "with patch" version again with logging enabled as you
suggest. Will update soon
On Thu, Nov 12, 2015 at 4:36 PM Jim Ingham <jing...@apple.com> 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
