Re: About handle_inferior_event new_thread_event

[Daniel Jacobowitz <drow@false.org>]

On Mon, Jun 29, 2009 at 12:29:12PM +0100, Pedro Alves wrote:
> seems to me that this is intended to have targets report new
> threads to the core by reporting e.g., TARGET_WAITKIND_STOP
> with any fake signal.  If the stop was due to a new thread event
> in the target side (as oposed to a signal that should really cause
> a stop), then the resume really lets the thread go free on the target
> side.  If otherwise, the stop was due to a real signal (a SIGTRAP, a
> SIGSEGV, etc.), then the resume causes the target to report the signal
> again (that's what happens on linux, for example), and so, handle_inferior
> event is again called to handle the same signal, only the second
> time, the thread is already listed, so the event goes on to be
> handled as usual.
> 
> I've always been curious as to which target relies on this, since
> the remote target always adds threads to the thread list
> before reporting events to the core (possibly due to the fact that
> there are targets where resuming with TARGET_SIGNAL_0 when stopped
> at a signal doesn't retrigger the pending signal).  Maybe this was
> something that was intended to be documented?  Anyone knows the
> history behind this?

I don't know - but I do know that this code has never worked reliably
for Linux; we used to get crashes or internal errors from unset
LWP-private state any time we went through here.  I'd rather all
targets were required to do thread accounting on their own.

-- 
Daniel Jacobowitz
CodeSourcery