From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17374 invoked by alias); 16 Aug 2002 14:42:50 -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 17351 invoked from network); 16 Aug 2002 14:42:47 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 16 Aug 2002 14:42:47 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3955C3C8C; Fri, 16 Aug 2002 10:42:42 -0400 (EDT) Message-ID: <3D5D0F62.4010207@ges.redhat.com> Date: Fri, 16 Aug 2002 07:42: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00187.txt.bz2 > 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 > 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. > 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. 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). Andrew