Fix TestThreadSpecificBreakpoint.py on Linux after rL252355.

Summary:
On Linux, if a thread-specific conditional breakpoint was hit, it
won't necessarily be the thread that hit the breakpoint itself that
evaluates the conditional expression, so the thread that hit the
breakpoint could still be asked to stop, even though it hasn't been
allowed to run since the previous stop.

Reviewers: sivachandra, jingham

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D14472

llvm-svn: 252391
This commit is contained in:
Chaoren Lin 2015-11-07 02:16:31 +00:00
parent 7123e2b5d7
commit 6e8fbc6f39
1 changed files with 5 additions and 1 deletions

View File

@ -262,7 +262,11 @@ ThreadList::ShouldStop (Event *event_ptr)
// This is an optimization... If we didn't let a thread run in between the previous stop and this
// one, we shouldn't have to consult it for ShouldStop. So just leave it off the list we are going to
// inspect.
if (thread_sp->GetTemporaryResumeState () != eStateSuspended)
// On Linux, if a thread-specific conditional breakpoint was hit, it won't necessarily be the thread
// that hit the breakpoint itself that evaluates the conditional expression, so the thread that hit
// the breakpoint could still be asked to stop, even though it hasn't been allowed to run since the
// previous stop.
if (thread_sp->GetTemporaryResumeState () != eStateSuspended || thread_sp->IsStillAtLastBreakpointHit())
threads_copy.push_back(thread_sp);
}