From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14199 invoked by alias); 25 Sep 2002 15:51:58 -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 14185 invoked from network); 25 Sep 2002 15:51:56 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 25 Sep 2002 15:51:56 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17uFOA-0004o7-00; Wed, 25 Sep 2002 11:51:50 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17uESM-0004a8-00; Wed, 25 Sep 2002 11:52:06 -0400 Date: Wed, 25 Sep 2002 08:51:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney , gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020925155206.GA17491@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> <20020828133445.GA16642@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020828133445.GA16642@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00409.txt.bz2 On Wed, Aug 28, 2002 at 09:34:45AM -0400, Daniel Jacobowitz wrote: > On Wed, Aug 28, 2002 at 12:06:38AM -0400, Andrew Cagney wrote: > > 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. Andrew, I was reminded today that this bug is still present, and we haven't come up with a solution for it. Do you have any ideas? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer