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
