Re: About handle_inferior_event new_thread_event

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> 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?

It's very old; it probably predates the code in remote.c that
you're referring to.  Can't really say which if any targets
still rely on it.

There's been a lot of evolution as far as thread list
accounting since that code was put in place.  In the
very early days, this was the only way we had of discovering
threads.  If a thread didn't get a stop event, gdb would
not know that thread existed.