From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19475 invoked by alias); 2 May 2002 20:13:23 -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 19467 invoked from network); 2 May 2002 20:13:21 -0000 Received: from unknown (HELO TheWorld.com) (199.172.62.106) by sources.redhat.com with SMTP; 2 May 2002 20:13:21 -0000 Received: from shell.TheWorld.com (mkatz@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA12147; Thu, 2 May 2002 16:13:20 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA794268; Thu, 2 May 2002 16:13:20 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Thu, 02 May 2002 13:13:00 -0000 From: Quality Quorum To: Andrew Cagney cc: Daniel Jacobowitz , Subject: Re: RFC: Two small remote protocol extensions In-Reply-To: <3CD15D5A.7020308@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-05/txt/msg00018.txt.bz2 On Thu, 2 May 2002, Andrew Cagney 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. > > 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. There some more annoying things in gdb protocol which require careful consideration: 1. zbreaks support by kind - how gdb can dynamically learn that particular kind of zbreak is not supported by target 2. zbreaks support by count - how gdb can dynamically learn that it is trying to set one zbreak too many. 3. reconnect - how target could learn that it got a connect from a new session so it has to forget about all zbreaks. 4. exact meaning of Hg - last time I checked it was related to registers 5. exact meaning of Hc - last time I check it did not mean anything because gdb itself was not able to support per thread breakpoints 6. gdb should be able to switch dynamically to soft-stepping if target does not support steps 7. Have configurable option to remove breakpoints before doing steps 8. Obsolete 'is-thread-alive'. Can somebody write a draft spec so we can discuss it as a whole, naturally, if you want you can start from one written by me but it is completely unnesessary - just clean-up the thing to truly usable state. > Andrew Thanks, Aleksey > > > 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 > >