From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18080 invoked by alias); 5 Nov 2002 20:59:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18037 invoked from network); 5 Nov 2002 20:59:04 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 5 Nov 2002 20:59:04 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 189BiO-0007l2-00; Tue, 05 Nov 2002 15:58:28 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 189Anl-0004CC-00; Tue, 05 Nov 2002 15:59:57 -0500 Date: Tue, 05 Nov 2002 12:59:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: Stand resume() on its head Message-ID: <20021105205957.GA15963@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3DC829E3.4090603@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DC829E3.4090603@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00060.txt.bz2 On Tue, Nov 05, 2002 at 03:28:19PM -0500, Andrew Cagney wrote: > Hello, > > There have now been several discussion threads that lead to the > conclusion that > > target->resume (ptid_t, int, enum target_signal) > > needs changing. At present the suggestion is to add a parameter to > indicate schedule locking and similar operations. > > I'd like to propose a different approach. Instead of passing to > resume() what to do, have resume() iterate over all the threads asking > each what it should do - suspend, step, run, signal, ... > > I think, in the end, GDB will need to do something like this any way > (how else is GDB going to handle suspended threads?) so might as well > start earlier rather than later :-) I like it, roughly speaking. I've got a couple of other thoughts and some questions: - What do you mean by suspended threads? - User interface for this? We could use this opportunity to fix and clarify passing signals. A command to show pending signals per-thread for the next resume; a command to set them. - Why would we want to step a particular thread in a resume? If we want to single-step a particular thread then it seems to me that we want to do it independently of resuming other threads. - Is there a useful way to combine this with a mechanism to report more than one event from a wait? More than one thread stopping with a signal, for instance. That'll also need interface changes, but we need the interface changes anyway: see the failing test for hitting a watchpoint and a breakpoint at the same time, in annota2.exp. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer