From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22899 invoked by alias); 16 Aug 2002 14:52:43 -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 22877 invoked from network); 16 Aug 2002 14:52:42 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Aug 2002 14:52:42 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17fiSt-0004YT-00; Fri, 16 Aug 2002 09:52:39 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17fiTK-0006Iw-00; Fri, 16 Aug 2002 10:53:06 -0400 Date: Fri, 16 Aug 2002 07:52:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020816145306.GA24002@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5D0F62.4010207@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00188.txt.bz2 On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote: > >On Wed, May 01, 2002 at 10:25:43PM -0400, Daniel Jacobowitz wrote: > > > >>In making remote thread debugging work on GNU/Linux, I needed two > >>additions > >>to the remote protocol. Neither is strictly necessary, but both are > >>useful, > >>IMHO. > >> > >>They are: > >> > >> - two new replies to the continue/step packets, 'n' and 'x'. They > >>indicate thread creation and death respectively, and are asynchronous; > >>the target is not stopped when they are sent. > > > > > >This one got shouted down, I'm not going to bring it up again. > > > > > >> - A new 'Hs' packet, paralleling Hc and Hg. This sets the "step" > >> thread. > > How is ``Hs'' different to: > > Hc > s Hc has a definite meaning right now. It means, step ONLY this thread. That corresponds to set scheduler-locking (on|step). Hc0 will be sent if we are not using scheduler locking. I see nothing wrong with the current meaning of Hc. Also, Hs was never meant to INCLUDE the step command. It sets a thread context, that's all. > >This one, however, needs feedback. A user just reported a bogus > >SIGTRAP bug to me which is fixed by the above. > > > >To elaborate on the problem: right now we have two ways of specifying a > >thread to the remote agent. Hg specifies the "general" thread, and Hc > >specifies the "continue" thread. These correspond to inferior_ptid and > >resume_ptid, roughly. > > > >When we single-step, if we are not using some form of > >scheduler-locking, resume_ptid is 0. We don't tell the agent at that > >point what inferior_ptid is; it has to step _some_ thread, and it picks > >one, and if it doesn't pick the one GDB expected we get problems. > > Shouldn't it pick the current-thread. As above. > >We need to either: > > - Communicate inferior_ptid via Hg at this time > > - Communicate inferior_ptid via a new Hs explicitly > > > >I think the former makes sense. Here's a patch; what do you think of > >it? Also included is the patch for gdbserver; I'd send a separate > >patch along afterwards to remove the vestiges of Hs from my testing, > >which escaped in the original threads patch. > > No. general thread is really ``selected thread'' the thread for which > the [gG][pP] packets apply. It is not involved in thread scheduling. We need two thread markers to step correctly; I think using this one is more logical. If you prefer then the code in gdbserver to use Hs is already there. > Separate to this is the user interface issue of, if you select a > different thread, and then do a step, things get real confused (I think > GDB tries to step the current (or stop) thread). No, actually, gdbserver is what gets confused. You've said this several times, and the last time you said it I went to check. In all my tests, both local (lin-lwp) and remote (with Hs patch), everything stepped the selected thread gracefully. This already works. Even scheduler locking works. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer