[Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range
Jim Ingham via lldb-commits
lldb-commits at lists.llvm.org
Fri Nov 13 10:39:16 PST 2015
Huh, I'll go check out that test. The basic functionality works on OS X:
(lldb) b s -n main
Breakpoint 1: 21 locations.
(lldb) run
Process 58218 launched: 'Sketch' (x86_64)
Process 58218 stopped
* thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 1.1
frame #0: 0x0000000100018dc7 Sketch`main at SKTMain.m:17
14 }
15
16 int main(int argc, const char *argv[]) {
-> 17 NSLog (@"Added for testing rebuilds.");
18 bool got_a_bool = NO;
19 NSString *text_to_use = @"٢٠ شباط";
20
(lldb) dis -p
Sketch`main:
-> 0x100018dc7 <+55>: movq %rax, %rdi
0x100018dca <+58>: movb $0x0, %al
0x100018dcc <+60>: callq 0x10001d21a ; symbol stub for: NSLog
0x100018dd1 <+65>: leaq 0xa530(%rip), %rcx ; @Sketch.__TEXT.__ustring + 0
(lldb) b s -a 0x100018dca
Breakpoint 2: where = Sketch`main + 58 at SKTMain.m:17, address = 0x0000000100018dca
(lldb) c
Process 58218 resuming
Process 58218 stopped
* thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 2.1
frame #0: 0x0000000100018dca Sketch`main at SKTMain.m:17
14 }
15
16 int main(int argc, const char *argv[]) {
-> 17 NSLog (@"Added for testing rebuilds.");
18 bool got_a_bool = NO;
19 NSString *text_to_use = @"٢٠ شباط";
20
Jim
> On 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
More information about the lldb-commits
mailing list