From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28077 invoked by alias); 2 May 2002 15:52:07 -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 28049 invoked from network); 2 May 2002 15:52:05 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 2 May 2002 15:52:05 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 173IsF-0003OT-00; Thu, 02 May 2002 11:52:03 -0400 Date: Thu, 02 May 2002 08:52:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020502155203.GA12647@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020502022543.GA22594@nevyn.them.org> <3CD15D5A.7020308@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD15D5A.7020308@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00011.txt.bz2 On Thu, May 02, 2002 at 11:38:02AM -0400, 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). That defeats the point of a fast thread debugging package. I do not want to stop threads at creation/death events; I put in quite a lot of work to avoid it. That scales very badly. The alternative was to just report all thread events at the next stop, but it is much more user-intuitive to do it immediately. Could you please explain why you are opposed to asynchronous notification? The 'O' packet doesn't seem to be "bad enough"; doing output notification synchronously just seems silly. (Note that they're still ack'd, like standard remote packets. It's just that the target isn't stopped.) > > - 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. When you step without scheduler locking, the normal GDB behavior is to step one thread and continue (then stop) all the others. Hc0 is sent beforehand to indicate that all threads should be continued. Which thread should be stepped? We can indicate this via Hg, since it has no meaning at that point; or we can indicate it via a new Hs. I don't care ;) > > 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 > > > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer