I'm unsure why it is eStopReasonTrace, I think that's something we inherited. Would eStopReasonNone or a new thread exiting stop reason be a better candidate? ________________________________________ From: Jim Ingham [[email protected]] Sent: Wednesday, December 19, 2012 2:12 PM To: Kaylor, Andrew Cc: Greg Clayton; Kopec, Matt; [email protected] Subject: Re: [lldb-dev] Limbo
Why is the stop reason for hitting this POSIXLimboStopInfo eStopReasonTrace. That's specifically the stop reason for single stepping, which should generally be handled by the plan that was doing the single stepping (and thus why there didn't need to be a handler for it in the Base thread plan.) I have no objections to adding a handler in ThreadPlanBase, but it seems weird to me that that's the stop reason for this Thread Exit stop event. Jim On Dec 19, 2012, at 10:47 AM, "Kaylor, Andrew" <[email protected]> wrote: > The current trunk implementation of POSIXLimboStopInfo is returning 'true' > for both ShouldStop() and ShouldNotify(). Having ShouldStop() return 'false' > gets the process to run to completion, but I get a line saying "Process <pid> > stopped and was programmatically restarted" even if I also return 'false' > from ShouldNotify(). > > To get rid of the 'restarted' message, I also have to add an > 'eStopReasonTrace' handler to ThreadPlanBase. > > The attached patch addresses all three of these changes. If it looks right > to everyone else I'll commit it. (BTW, this is adapted from some earlier > work that Matt did that had never been committed to trunk, but I think we've > done some testing with it here on Linux, Mac and FreeBSD.) > > -Andy > > -----Original Message----- > From: Greg Clayton [mailto:[email protected]] > Sent: Tuesday, December 18, 2012 4:14 PM > To: Kopec, Matt > Cc: Kaylor, Andrew; Jim Ingham; [email protected] > Subject: Re: [lldb-dev] Limbo > > > On Dec 18, 2012, at 2:34 PM, "Kopec, Matt" <[email protected]> wrote: > >> When multi-threading debugging works on Linux, this signal would be received >> for any inferior thread which exits, including non-main spawned threads. It >> would be possible for another thread to hit a breakpoint in this case. I'm >> wondering whether its' even useful to stop lldb/create a limbo stop reason >> when a thread exits? Is there any usefulness to examining a thread in limbo >> state (ie. a thread finished execution, it's about to exit. we can read >> registers...)? if anything, we would update the process thread list to >> remove the exiting thread and make sure it exits but I don't think the >> debugger needs to stop for this. > > If the thread is exiting and nothing can be done with it, it shouldn't even > be in the process thread list. Just omit any threads in this state and do any > cleanup needed to reap it/let it die. > >> >> Matt >> ________________________________________ >> From: [email protected] [[email protected]] on behalf >> of Kaylor, Andrew [[email protected]] >> Sent: Tuesday, December 18, 2012 5:12 PM >> To: Jim Ingham >> Cc: [email protected] >> Subject: Re: [lldb-dev] Limbo >> >> Hi Jim, >> >> We're setting the limbo state because we got a 'SIGTRAP | PTRACE_EVENT_EXIT >> << 8' signal -- that is, the inferior process is exiting. It looks like >> this is only getting used by Linux and FreeBSD. >> >> I'm not sure it's even possible for another thread to hit a breakpoint at >> this stage, but if it is then the behavior you describe is what we'd want. >> >> -Andy >> >> -----Original Message----- >> From: Jim Ingham [mailto:[email protected]] >> Sent: Tuesday, December 18, 2012 1:51 PM >> To: Kaylor, Andrew >> Cc: [email protected] >> Subject: Re: [lldb-dev] Limbo >> >> I don't know enough about the Linux threading model to know what is really >> going on. Is the thread being in this "Limbo" state the reason why the >> process as a whole stopped, or did it stop for some other reason, and the >> thread in Limbo is just along for the ride? If the latter, then should it >> have a stop reason at all? In general, in lldb, threads only have stop >> reasons if they were one of the threads that caused the process to stop. >> >> You are achieving pretty much the same thing by returning false from its >> ShouldStop. But note that if you happen to hit a breakpoint on another >> thread when the Limbo'ed thread exists, then both threads will be reported >> to have stopped, one with reason breakpoint and one "thread exited". Is >> that what you want? >> >> Jim >> >> On Dec 18, 2012, at 1:24 PM, "Kaylor, Andrew" <[email protected]> >> wrote: >> >>> There's an issue on Linux where LLDB stop with "stop reason = thread >>> exited" and displays a brief assembly dump from somewhere in libc. This >>> seems to happen because it is stopping in the "limbo" state. I can make it >>> go away by having POSIXLimboStopInfo::ShouldStop() return false instead of >>> true. >>> >>> Is there any reason I shouldn't do that? >>> >>> Thanks, >>> Andy >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > <limbo-stop-plan.patch> _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
