[lldb-dev] Limbo

[Jim Ingham]

So if the process actually gets a signal and stops on thread exit, then I'm inclined to think you should use the StopInfo mechanism, since that's the general mechanism for handling target stops, and subverting it doesn't seem wise.  As Andrew pointed out, returning false to the ShouldStop will mean you won't ever stop.  Then the other bit is whether the user should be notified about the stop info.  That's already needed in the case where thread A has stopped for an internal breakpoint and thread B has stopped for a user breakpoint.  In that case, you want to tell them about the user breakpoint but not the internal breakpoint.  That is governed by the StopInfo's ShouldNotify function.  So for instance, in the StopInfoBreakpoint, it checks whether the breakpoint is internal or not and returns true or false accordingly.  So you could use the same mechanism for these Limbo stop events.  They should just always return false to ShouldNotify.  That way, for instance, if you needed to do something when a thread exits you could stuff it into the StopInfo's PerformAction...

I have a sneaking suspicion that there are some places in lldb that don't obey the ShouldNotify, because I have occasional reports of some of our internal breakpoint hits getting printed.  But I haven't had time to go track down who the bad guy is yet.  But that is the way it is supposed to work, and seems a pretty reasonable scheme...

Jim


On Dec 18, 2012, at 2:34 PM, "Kopec, Matt" <matt.kopec at intel.com> 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.
> 
> Matt
> ________________________________________
> From: lldb-dev-bounces at cs.uiuc.edu [lldb-dev-bounces at cs.uiuc.edu] on behalf of Kaylor, Andrew [andrew.kaylor at intel.com]
> Sent: Tuesday, December 18, 2012 5:12 PM
> To: Jim Ingham
> Cc: lldb-dev at cs.uiuc.edu
> 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:jingham at apple.com]
> Sent: Tuesday, December 18, 2012 1:51 PM
> To: Kaylor, Andrew
> Cc: lldb-dev at cs.uiuc.edu
> 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" <andrew.kaylor at intel.com> 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
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev