From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5637 invoked by alias); 23 Aug 2002 02:23:18 -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 5626 invoked from network); 23 Aug 2002 02:23:17 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 23 Aug 2002 02:23:17 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 41BD73C48; Thu, 22 Aug 2002 22:23:15 -0400 (EDT) Message-ID: <3D659C93.4030807@ges.redhat.com> Date: Thu, 22 Aug 2002 19:23:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00276.txt.bz2 Lets get rid of the easy one (...) `Hg': `` @item @code{Hg}@var{id} --- set general thread @cindex @code{Hc} packet Select the general thread. Register and memory read and write operations apply to the most recently selected general thread. @var{id}, a hex encoded cardinal, is the identifier of the selected thread. After a target stop, the general thread is reset to the thread identifier of the stopped thread. @emph{Implementation note: The @code{Hg} packet can not be used to determine the most recently selected thread (using the @samp{thread @var{thread-id} command). This is because @value{GDBN} can cache per-thread data and avoid the need to re-query the target on each @samp{thread} command.} @c Note the word ``can'' is used, not ``does'' :-) Reply: @table @samp @item OK for success @item E00 unspecified error @c ESRCH --- no such proces/thread? @item @samp{} unsupported @end table '' Andrew > 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