This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

About handle_inferior_event new_thread_event


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]