From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15643 invoked by alias); 27 Sep 2002 01:39:51 -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 15635 invoked from network); 27 Sep 2002 01:39:50 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 27 Sep 2002 01:39:50 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1B8A33E1B; Thu, 26 Sep 2002 21:39:51 -0400 (EDT) Message-ID: <3D93B6E6.8030805@redhat.com> Date: Thu, 26 Sep 2002 18:39: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@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00472.txt.bz2 > 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. Yes, to come full circle, I can see two choices: - (me back down) and Hg be made as per your proposal - as well as the registers, it also specify the thread to step when there isn't thread locking. - we define something properly - we modify GDB so that, when asked to step a thread other than current (i.e., selected) GDB first forces the target to switch to that thread, and then steps it. This means doing a software single step even though the hardware might think it has hardware single step. Separate to this GDB needs to be changed to that resume() has all the information it needs to implement all of the above operations (and it isn't relying on that implied global state :-( ). > > 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. I really don't know. (For ``s'', should you be stepping all threads?) Anyway, I think, to do this right, we're left needing a new packet. Try: >> > step one, stop others > >> >> Hardware single-step off of breakpoint. >> TPID, STEP, !OTH >> HcTID, s HtTID;s >> > step one, continue others > >> >> Hardware single-step. >> TPID, STEP, OTH >> H???, s HtPID,0;s or even: Ht0;s I.e., step all threads. Let GDB sort out the mess. >> > continue one, stop others > >> >> Schedule lock. >> Software single-step off breakpoint. >> TPID, !STEP, !OTH (wiered) >> HcTID, c HtTID;c >> > continue one, continue others > >> >> Software single-step. >> General resume. >> TPID, !STEP, OTH >> Hc0, c Ht0;c or c And also: HtTID;g HtTID,TID,TID;Z... HtTID,TID,TID;c etc. Andrew