[Lldb-commits] [PATCH] D16767: Fix single-stepping onto a breakpoint

[Pavel Labath via lldb-commits]

labath added a comment.

In http://reviews.llvm.org/D16767#341259, @amccarth wrote:

> I was chasing this same bug on Windows before I noticed you were working on it.  I patched in your latest diff, and the problem still occurs.


That is not surprising. These fixes (r259344, and this one) are implemented in the os-specific classes: ProcessFreeBSD (used on freebsd, obviously), and ProcessGdbRemote (used on arches using lldb-server: linux, osx). I don't really like that, as I think this functionality could be abstracted to a common place, but that seems to be the way things are done currently. You could probably fix this by doing something similar in ProcessWindows. I.e., when you get a "stopped by single-step" event from the OS, check whether there is a breakpoint under your instruction, and if it is, report that as a breakpoint hit instead.

> > FAIL: test_continue (TestConsecutiveBreakpoints.ConsecutiveBreakpointsTestCase)

> 

> > 

> 

> >   Test that continue stops at the second breakpoint.

> 

> > 

> 

> >  ----------------------------------------------------------------------

> 

> > 

> 

> > Traceback (most recent call last):

> 

> > 

> 

> >   File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 552, in wrapper

> 

> >     return func(self, *args, **kwargs)

> 

> >   File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\breakpoint\consecutive_breakpoints\TestConsecutiveBreakpoints.py", line 58, in test_continue

> 

> >     self.assertEquals(self.process.GetState(), lldb.eStateStopped)

> 

> > 

> 

> > AssertionError: 10 != 5

> 


This is what the original test was doing. It just fails slightly sooner, because I added a new assert (10 is eStateExited, so your inferior exits because it failed to stop at the second breakpoint).

> > FAIL: test_single_step (TestConsecutiveBreakpoints.ConsecutiveBreakpointsTestCase)

> 

> > 

> 

> >   Test that single step stops at the second breakpoint.

> 

> > 

> 

> >  ----------------------------------------------------------------------

> 

> > 

> 

> > Traceback (most recent call last):

> 

> > 

> 

> >   File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 552, in wrapper

> 

> >     return func(self, *args, **kwargs)

> 

> >   File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\breakpoint\consecutive_breakpoints\TestConsecutiveBreakpoints.py", line 76, in test_single_step

> 

> >     self.assertIsNotNone(self.thread, "Expected one thread to be stopped at breakpoint 2")

> 

> > 

> 

> > AssertionError: unexpectedly None : Expected one thread to be stopped at breakpoint 2

> 


This is sort of testing the same thing, only it's using a single step command instead. I added it "by the way", while I was adding the third test. The failure mode is different as I didn't put the assert on the process state (I probably should do that). Hopefully you will be able to fix both failures in one go.

> > RESULT: FAILED (1 passes

> 


This is the regression introduced by the first patch. Without my fix the single step operation wouldn't stop correctly because of the thread-specific breakpoint. You want to make sure you don't regress here while fixing the first two.

I am going ahead and committing this, as I don't think it will cause any regressions on your side. Let me know if you have any concerns.


http://reviews.llvm.org/D16767