About handle_inferior_event new_thread_event

Pedro Alves
2009-06-29T11:28:17Z

This bit of code in handle_inferior_event:

/* If it's a new process, add it to the thread database */

ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
&& !ptid_equal (ecs->ptid, minus_one_ptid)
&& !in_thread_list (ecs->ptid));

...

if (ecs->new_thread_event)
{
...
/* We may want to consider not doing a resume here in order to
give the user a chance to play with the new thread. It might
be good to make that a user-settable option. */

/* At this point, all threads are stopped (happens automatically
in either the OS or the native code). Therefore we need to
continue all threads in order to make progress. */

target_resume (RESUME_ALL, 0, TARGET_SIGNAL_0);
prepare_to_wait (ecs);
return;
}

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?

--
Pedro Alves