The StopInfo generation isn't done quite right: the process plugin has all the responsibility for generating the StopInfo. There really should be a Process base class function that gets to revise the stop reason after the plugin determines it. One unfortunate effect of not having that is that the conversion of StopInfoBreakpoint to no stop reason for thread specific breakpoints is done in the Process plugins, which allows a plugin author to get it wrong... OTOH, it looks like POSIXThread::BreakNotify is doing the right thing.
On a side note, I'm not quite sure why POSIXThread::BreakNotify is selecting the thread that hit the breakpoint. There's code at a higher level that tries to keep the selected thread consistent (so for instance if you did a next on Thread A, and then hit breakpoints on threads A & B, it would keep A the selected thread.) Selecting the thread when you make the StopInfo will defeat that attempt. Jim On Sep 19, 2013, at 9:17 AM, Kopec, Matt <[email protected]> wrote: > We have a spurious failure in the TestThreadStepOut test mentioned and when > it fails the stop reason for the stepping out thread is none rather then > 'step out'. ThreadPlanStepOut is most likely alright, it's probably an issue > with the Linux plugin. I was trying to understand the expected behaviour in > this use case. > > Thanks, > Matt > > On 2013-09-18, at 6:49 PM, [email protected] wrote: > >> This shouldn't require any extra effort, however, since the "step out >> breakpoint" set in the ThreadPlanStepOut is set as thread specific for that >> thread. If a thread specific breakpoint is hit by a different thread, the >> process is just auto-continued without notifying the thread of the stop. >> And in fact, the stop reason of that thread is set to nothing so if you >> happen to hit a thread specific breakpoint on two threads simultaneously, >> only the one set for that breakpoint will see a stop reason of "breakpoint >> hit". So the correct behavior should obtain automatically. If it doesn't >> it means something about thread specific breakpoints is broken. >> >> Jim >> >> On Sep 18, 2013, at 3:43 PM, [email protected] wrote: >> >>> Step out breakpoints are always thread specific, since they implement >>> operations for one specific thread. So conceptually there is no breakpoint >>> at the step out destination for thread B, though in practice this means if >>> thread B hits the step out breakpoint it should continue without stopping. >>> Is this not working? >>> >>> Jim >>> >>> On Sep 18, 2013, at 3:37 PM, Kopec, Matt <[email protected]> wrote: >>> >>>> Hi Jim, >>>> >>>> A question came up about the correct behavior when a thread hits a >>>> step-out breakpoint that was intended for another thread. >>>> >>>> In the TestThreadStepOut test case, two threads are stopped inside the >>>> same function (invoked from the same call site) and Thread A is issued a >>>> ‘thread step-out –m all-threads’. What should happen if Thread B hits the >>>> step-out breakpoint before Thread A? Should Thread B continue past the >>>> breakpoint or stop there until Thread A finishes the step-out? >>>> >>>> Thanks, >>>> Matt >>> >> > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
