[Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range
Zachary Turner via lldb-commits
lldb-commits at lists.llvm.org
Fri Nov 13 09:24:35 PST 2015
Ahh, good to know. Thanks!
On Fri, Nov 13, 2015 at 2:47 AM Tamas Berghammer <tberghammer at google.com>
wrote:
> We already have a test for it in TestConsecutiveBreakpoints.py what is
> xfail-ed on all platform because of this bug (http://llvm.org/pr23478). As
> far as I see from the build bots the test is also failing on OSX, but it
> might fail from a different reason then on Linux/Windows.
>
> On Fri, Nov 13, 2015 at 4:10 AM Zachary Turner via lldb-commits <
> lldb-commits at lists.llvm.org> wrote:
>
>> Thanks! Do you think you could add a test that does specifically that?
>> Set two breakpoints back to back, even in the same function, ane ensure
>> that the second one gets hit. If your theory is right this test will fail
>> on Windows and Linux (and then we'll have to xfail it) but at least we'll
>> have a test that's isolated to the root of the problem.
>>
>> On Thu, Nov 12, 2015 at 7:47 PM Jim Ingham <jingham at apple.com> wrote:
>>
>>> 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 <zturner at 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 <chying at 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 at 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 <zturner at 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 <jingham at 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 <zturner at 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 at 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 at lists.llvm.org
>>> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>> > >
>>> >
>>> > _______________________________________________
>>> > lldb-commits mailing list
>>> > lldb-commits at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>> >
>>>
>>> _______________________________________________
>> lldb-commits mailing list
>> lldb-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151113/cbc10962/attachment-0001.html>
More information about the lldb-commits
mailing list