Here's the log. Disassembly of those two functions was posted earlier.
Let me know if you need anything else:
ThreadPlanStepRange::SetNextBranchBreakpoint - Setting breakpoint -1 (site
2) to run to address 0x94902e
Thread::PushPlan(0x0654FBB0): "Stepping in through line with-debug.c:12.",
tid = 0xb6b0.
Process::PrivateResume() m_stop_id = 2, public state: stopped private
state: stopped
Thread::PushPlan(0x0654FBB0): "Single stepping past breakpoint site 1 at
0x94902b", tid = 0xb6b0.
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
Process thinks the process has resumed.
Current Plan for thread 1(0654FBB0) (0xb6b0, stepping): Step over
breakpoint trap being asked whether we should report run.
ThreadList::lldb_private::ThreadList::ShouldStop: 1 threads, 1 unsuspended
threads
Thread::lldb_private::Thread::ShouldStop(0654FBB0) for tid = 0xb6b0 0xb6b0,
pc = 0x000000000094902e
^^^^^^^^ Thread::ShouldStop Begin ^^^^^^^^
Plan stack initial state:
thread #1: tid = 0xb6b0:
Active plan stack:
Element 0: Base thread plan.
Element 1: Stepping in through line with-debug.c:12 using
ranges:[0x0094902b-0x0094902e).
Element 2: Single stepping past breakpoint site 1 at 0x94902b
Plan Step over breakpoint trap explains stop, auto-continue 1.
Plan Step over breakpoint trap should stop: 0.
Completed step over breakpoint plan.
Popping plan: "Step over breakpoint trap", tid = 0xb6b0.
ThreadPlanStepInRange reached 0x0094902e.
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
Plan Step Range stepping in should stop: 0.
Plan stack final state:
thread #1: tid = 0xb6b0:
Active plan stack:
Element 0: Base thread plan.
Element 1: Stepping in through line with-debug.c:12 using ranges: 0:
[0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).
Completed Plan Stack:
Element 0: Single stepping past breakpoint site 1 at 0x94902b
vvvvvvvv Thread::ShouldStop End (returning 0) vvvvvvvv
ThreadList::lldb_private::ThreadList::ShouldStop overall should_stop = 0
ThreadList::lldb_private::ThreadList::ShouldReportStop 1 threads
Thread::ShouldReportStop() tid = 0xb6b0: returning vote for complete
stack's back plan
ThreadPlan::ShouldReportStop() returning vote: no
ThreadList::lldb_private::ThreadList::ShouldReportStop returning no
Process::PrivateResume() m_stop_id = 3, public state: running private
state: stopped
Thread::PushPlan(0x0654FBB0): "Single stepping past breakpoint site 2 at
0x94902e", tid = 0xb6b0.
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
Process thinks the process has resumed.
ThreadList::lldb_private::ThreadList::ShouldStop: 1 threads, 1 unsuspended
threads
Thread::lldb_private::Thread::ShouldStop(0654FBB0) for tid = 0xb6b0 0xb6b0,
pc = 0x0000000000949031
^^^^^^^^ Thread::ShouldStop Begin ^^^^^^^^
Plan stack initial state:
thread #1: tid = 0xb6b0:
Active plan stack:
Element 0: Base thread plan.
Element 1: Stepping in through line with-debug.c:12 using ranges: 0:
[0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).
Element 2: Single stepping past breakpoint site 2 at 0x94902e
Plan Step over breakpoint trap explains stop, auto-continue 1.
Plan Step over breakpoint trap should stop: 0.
Completed step over breakpoint plan.
Popping plan: "Step over breakpoint trap", tid = 0xb6b0.
ThreadPlanStepInRange reached 0x00949031.
Plan Step Range stepping in should stop: 0.
Plan stack final state:
thread #1: tid = 0xb6b0:
Active plan stack:
Element 0: Base thread plan.
Element 1: Stepping in through line with-debug.c:12 using ranges: 0:
[0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).
Completed Plan Stack:
Element 0: Single stepping past breakpoint site 2 at 0x94902e
vvvvvvvv Thread::ShouldStop End (returning 0) vvvvvvvv
ThreadList::lldb_private::ThreadList::ShouldStop overall should_stop = 0
ThreadList::lldb_private::ThreadList::ShouldReportStop 1 threads
Thread::ShouldReportStop() tid = 0xb6b0: returning vote for complete
stack's back plan
ThreadPlan::ShouldReportStop() returning vote: no
ThreadList::lldb_private::ThreadList::ShouldReportStop returning no
Process::PrivateResume() m_stop_id = 4, public state: running private
state: stopped
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
Process thinks the process has resumed.
Removing next branch breakpoint: -1.
On Thu, Nov 12, 2015 at 4:40 PM Zachary Turner <ztur...@google.com> wrote:
> 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
