From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1142 invoked by alias); 19 May 2008 15:19:28 -0000 Received: (qmail 1134 invoked by uid 22791); 19 May 2008 15:19:28 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 May 2008 15:19:10 +0000 Received: (qmail 9399 invoked from network); 19 May 2008 15:19:08 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 May 2008 15:19:08 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] 07/10 non-stop inferior control Date: Mon, 19 May 2008 16:55:00 -0000 User-Agent: KMail/1.9.9 Cc: Daniel Jacobowitz References: <200805061649.24082.pedro@codesourcery.com> <200805090222.51406.pedro@codesourcery.com> <20080509014454.GA22833@caradoc.them.org> In-Reply-To: <20080509014454.GA22833@caradoc.them.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200805191619.08350.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00559.txt.bz2 A Friday 09 May 2008 02:44:54, Daniel Jacobowitz wrote: > On Fri, May 09, 2008 at 02:22:51AM +0100, Pedro Alves wrote: > > Isn't this new_thread_event handling a bandaid for some > > misbehaving target? My understanding was that targets should handle > > new thread events (and call add_thread*) themselves nowadays. > > That might be a little strong; but the Linux and remote targets do so, > because it was much more convenient. > Ok. If you know off-hand of any target that relies on new_thread_event, I'd like to get to know it. I think it's very bad to rely on core GDB to do add threads. context_switch needed to be bandaided for cases where threads are not managed by the target. We can't distinguish a case of the target escaping a bad ptid_t due to a bug from a valid event. The comments around this aren't too optimistic. static void context_switch (ptid_t ptid) { /* Caution: it may happen that the new thread (or the old one!) is not in the thread list. In this case we must not attempt to "switch context", or we run the risk that our context may be lost. This may happen as a result of the target module mishandling thread creation. */ static void record_currthread (int currthread) { general_thread = currthread; /* If this is a new thread, add it to GDB's thread list. If we leave it up to WFI to do this, bad things will happen. */ if (!in_thread_list (pid_to_ptid (currthread))) add_thread (pid_to_ptid (currthread)); The only benefit of letting the core handle new threads, would be to add support to stop on new thread events. But, this form is of questinable value. I would argue for implementing that with events/catchpoints, and/or a new target_waitstatus. > > Since this is a new mode that will require adaptation > > by each target, it sounded reasonable to require that the > > the new_thread_event should never be hit, and that the > > target handles adding threads to GDB's thread list. > > If documented in gdbint, I think this would be a reasonable new > restriction. Ok. I haven't managed to get to the docs yet, but I'll get to it. -- Pedro Alves