From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15021 invoked by alias); 2 May 2002 15:38:02 -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 14957 invoked from network); 2 May 2002 15:38:00 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 2 May 2002 15:38:00 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7ACBD3D74; Thu, 2 May 2002 11:38:02 -0400 (EDT) Message-ID: <3CD15D5A.7020308@cygnus.com> Date: Thu, 02 May 2002 08:38:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00010.txt.bz2 > 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. No. Telling GDB of thread create/delete events is a good idea, but please, do it synchronously (we've already got the ``O'' packet and that is bad enough). Have you tried: T00Thread....? for the create event. (signal 0 is loosely defined as a non-event). > - A new 'Hs' packet, paralleling Hc and Hg. This sets the "step" thread. I don't know. What is the difference between Hc and Hs? BTW, Hg is orthogonal to the step/continue problem. Anyway, I suspect Michael knows more than most on this front and this needs very careful consideration. Andrew > Basically, despite a comment that it didn't work earlier on this list, I > discovered that lin-lwp does correctly honor `set scheduler-locking'. It > works by controlling which threads are resumed by resume_ptid. However, > for stepping, inferior_ptid is also consulted. That way all threads can > be resumed but a particular thread stepped. The `thread ' command > changes the thread to be stepped. > > resume_ptid is communicated to the remote host. inferior_ptid is not > necessarily the same as general_ptid, however - after information requests > like `thread apply all bt', for instance. Yes. Hg has nothing to do with Hc. > Reading over the above, I suppose I could use general_ptid for this instead, > with a slightly smaller patch to remote_resume to guarantee that it is set. > That makes a little more sense than my current approach. Still needs a > documentation patch to clarify it; I intend to fix up most of the protocol > specification (which is woefully out of date, and hideous in texinfo) as > soon as I get a chance. > > Any thoughts on the two above changes? > > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer