From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29738 invoked by alias); 29 Jun 2009 11:28:17 -0000 Received: (qmail 29729 invoked by uid 22791); 29 Jun 2009 11:28:17 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 11:28:11 +0000 Received: (qmail 30256 invoked from network); 29 Jun 2009 11:28:09 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Jun 2009 11:28:09 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: About handle_inferior_event new_thread_event Date: Mon, 29 Jun 2009 11:28:00 -0000 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291229.12382.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00295.txt.bz2 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