From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17188 invoked by alias); 28 Aug 2002 13:33:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17168 invoked from network); 28 Aug 2002 13:33:40 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 28 Aug 2002 13:33:40 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17k3tH-0004QS-00; Wed, 28 Aug 2002 09:33:51 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17k2y5-0004OF-00; Wed, 28 Aug 2002 09:34:45 -0400 Date: Wed, 28 Aug 2002 06:33:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020828133445.GA16642@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020502022543.GA22594@nevyn.them.org> <20020816143040.GA22041@nevyn.them.org> <3D5D0F62.4010207@ges.redhat.com> <20020816145306.GA24002@nevyn.them.org> <3D65B53D.8050603@ges.redhat.com> <20020823124453.GA12257@nevyn.them.org> <3D6692AE.90601@ges.redhat.com> <20020823201549.GB26809@nevyn.them.org> <3D6C4C4E.4050409@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6C4C4E.4050409@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00376.txt.bz2 On Wed, Aug 28, 2002 at 12:06:38AM -0400, Andrew Cagney wrote: > > >Sure. I suppose we should clean up the interface to resume, to prevent > >all this confusion re-arising... which means figuring out our possible > >behaviors, and whether they are even implementable on particular > >targets. > > The spanner in the works here is simulators. They can't implement > schedule-locking because their scheduler is hardwired. The best they > can manage is step off current instruction. > > A simple version of this (PPC) (from memory) always implements > step->schedule. If you step I the procesor. It complets one > instruction on the current CPU and then schedules the next CPU for the > next instruction. OK, makes sense. > >On Linux the options for any given LWP (at the moment, that means for > >any given thread) are step, run, stop. All combinations are available. > >I think the _useful_ ones are: > > > > step one, stop others > > step one, continue others > > continue one, stop others > > continue one, continue others > > > >And, of course: > > stop one, stop others > >:) > > > > What is the absolute minimum needed? > > - step off breakpoint / thread-hop > = using a sched lock single-step > = using software single-step breakpoints and a sched lock continue > (Note: this is where the existing interface really falls down -- step=0 > so remote.c won't know to schedule-lock) > > - continue > > I think, after that, everything is an efficiency gain. Looking at the list: > > > step one, stop others > > Hardware single-step off of breakpoint. > TPID, STEP, !OTH > HcTID, s > > > step one, continue others > > Hardware single-step. > TPID, STEP, OTH > H???, s > > > continue one, stop others > > Schedule lock. > Software single-step off breakpoint. > TPID, !STEP, !OTH (wiered) > HcTID, c > > > continue one, continue others > > Software single-step. > General resume. > TPID, !STEP, OTH > Hc0, c > > > Something like: > > resume (ptid, step, run_others, target_signal) > > maybe? Does anyone think step_all is useful (I don't)? > > It is what a simulator might implement. > > So looking at the remote protocol. There in't a way of specifying TPID, > STEP, OTH (your bug). OK, I suppose that makes sense. It's pretty much where I was to begin with: if Hc is non-zero, lock to that thread; if Hc is 0, resume all threads, but where do we step? How would you like to see us specify this - I used Hs, a new step packet taking a thread argument might work too... etc. There's also the question of whether any other simulators or targets handle this, and how they behave; I'm not familiar with them. Do they treat "HcTID, s" as single-step-one-thread-only? I guess they probably do. > >PS: > >Some day letting the user be more precise (run these two threads) would > >be nice. I envision a day in the distant future: > > -> Continue thread 1 > > -> Continue thread 2 > > -> Wait for inferior status > > <- All threads stopped, thread 1, SIGSEGV > >or > > -> Continue all threads > > -> Wait for inferior status [maybe implicit in the all-threads > > request] > > <- Thread 1 stopped, shared lib breakpoint, all other threads running > > Try ``target remote-async''. Yes, that has the general model that I'm looking for, but this requires some protocol changes - the protocol would be async-only. It wouldn't make sense as a synchronous protocol. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer