From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27169 invoked by alias); 5 Nov 2002 23:10:03 -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 27119 invoked from network); 5 Nov 2002 23:10:02 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 5 Nov 2002 23:10:02 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 132E83F3B; Tue, 5 Nov 2002 18:10:03 -0500 (EST) Message-ID: <3DC84FCA.50001@redhat.com> Date: Tue, 05 Nov 2002 15:10:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: 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; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00075.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? Per Michael's comment when the user explicitly suspends a thread. Also, a thread-hop would mean suspending some threads, single-stepping one. > - 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. For the moment none :-) However, yes, down the track that will become possible. The other side of this would be having each thread's state updated as it arrived (instead of reaping all the status and then going back to wfi). > - 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. The remote Hc discussion identified two cases: - thread-hop - single-step thread In the case of shlib, all the other threads would already being in the running state (so would need no action). Just one stopped thread would need a stepi. > - 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. I think we'll need that anyway. But hopefully independentish - resume can be implemented independant of the wait side. > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer Andrew