summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
diff options
context:
space:
mode:
authorGreg Clayton <gclayton@apple.com>2015-04-07 22:17:41 +0000
committerGreg Clayton <gclayton@apple.com>2015-04-07 22:17:41 +0000
commitab745c2ad865c07f3905482fd071ef36c024713a (patch)
tree8d01a1a5354618d3f25df18d5d38fa659ee56d74 /lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
parent61a5bbf92a25d1f8aa32a09b132f35a6b2a69f26 (diff)
downloadbcm5719-llvm-ab745c2ad865c07f3905482fd071ef36c024713a.tar.gz
bcm5719-llvm-ab745c2ad865c07f3905482fd071ef36c024713a.zip
Fix stepping a virtual thread when the python operating system was enabled.
The OperatingSystem plug-ins allow code to detect threads in memory and then say "memory thread 0x11111" is backed by the actual thread 1. You can then single step these virtual threads. A problem arose when thread specific breakpoints were used during thread plans where we would say "set a breakpoint on thread 0x11111" and we would hit the breakpoint on the real thread 1 and the thread IDs wouldn't match and we would get rid of the "stopped at breakpoint" stop info due to this mismatch. Code was added to ensure these events get forwarded and thus allow single stepping a memory thread to work correctly. Added a test case for this as well. <rdar://problem/19211770> llvm-svn: 234364
Diffstat (limited to 'lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp')
-rw-r--r--lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp7
1 files changed, 5 insertions, 2 deletions
diff --git a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
index a69b38b6c93..7c68d0d0782 100644
--- a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
+++ b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
@@ -498,12 +498,15 @@ StopInfoMachException::CreateStopReasonWithMachException
// If the breakpoint is for this thread, then we'll report the hit, but if it is for another thread,
// we can just report no reason. We don't need to worry about stepping over the breakpoint here, that
// will be taken care of when the thread resumes and notices that there's a breakpoint under the pc.
- if (bp_site_sp->ValidForThisThread (&thread))
+ // If we have an operating system plug-in, we might have set a thread specific breakpoint using the
+ // operating system thread ID, so we can't make any assumptions about the thread ID so we must always
+ // report the breakpoint regardless of the thread.
+ if (bp_site_sp->ValidForThisThread (&thread) || thread.GetProcess()->GetOperatingSystem () != NULL)
return StopInfo::CreateStopReasonWithBreakpointSiteID (thread, bp_site_sp->GetID());
else
return StopInfoSP();
}
-
+
// Don't call this a trace if we weren't single stepping this thread.
if (is_trace_if_actual_breakpoint_missing && thread.GetTemporaryResumeState() == eStateStepping)
{
OpenPOWER on IntegriCloud