From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14172 invoked by alias); 5 Nov 2002 22:15:26 -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 14165 invoked from network); 5 Nov 2002 22:15:25 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 5 Nov 2002 22:15:25 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA5Lqqw27501 for ; Tue, 5 Nov 2002 16:52:53 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA5MFLl23741; Tue, 5 Nov 2002 17:15:22 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gA5MFFD16935; Tue, 5 Nov 2002 14:15:15 -0800 Message-ID: <3DC842F3.2E4B9197@redhat.com> Date: Tue, 05 Nov 2002 14:15:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: Stand resume() on its head References: <3DC829E3.4090603@redhat.com> <20021105205957.GA15963@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00069.txt.bz2 Daniel Jacobowitz wrote: > > 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? Just what you think -- give the user the ability to say "this thread should not resume when the others do." > - User interface for this? Important, and yet to be worked out. Wanna start the discussion? > 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. Hmmmm! > - 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. Currently that's true. I can't think of a circumstance where it wouldn't be true, but I haven't thought real hard about it. > - 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. In a single-processor system, I don't think that can happen. It's bogus that Linux-gdb lets it appear to happen (at least internally). But yeah, it can sure happen in a multi-processor environment. Have any thoughts to share about that interface? Michael