From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22558 invoked by alias); 2 May 2002 21:09:09 -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 22520 invoked from network); 2 May 2002 21:09:06 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 2 May 2002 21:09:06 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 173Np6-0006fB-00; Thu, 02 May 2002 17:09:08 -0400 Date: Thu, 02 May 2002 14:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020502210908.GA25410@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020502022543.GA22594@nevyn.them.org> <3CD15D5A.7020308@cygnus.com> <20020502155203.GA12647@nevyn.them.org> <3CD16BC9.2010209@cygnus.com> <20020502191411.GB19130@nevyn.them.org> <3CD19DEB.2010803@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD19DEB.2010803@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00021.txt.bz2 On Thu, May 02, 2002 at 04:13:31PM -0400, Andrew Cagney wrote: > >These are threading information packets. They are completely optional, > >and I believe that they are of an appropriate nature for the > >environments which support it; such systems generally: > > Optional or not, it needs to be reliable. You need to be able to run a > test cases 1000 times and have it pass 1000 times. I really do not see what is unreliable here. They're still ACKed... > > a) Should have no trouble implementing asynchronous responses. > > It needed about fifteen lines of code changed in gdbserver, > > so most Unix-alikes should be fine. VxWorks could certainly > > do it as well. > > > > b) Desire the least-intrusive possible thread debugging. > > These aren't niche events; in a multithreaded application, > > thread creation and deletion can happen very frequently, and > > with a large number of running threads. I've heard a lot > > of complaints about how much our intrusive thread debugging > > harasses scheduler priorities. > > > >I'd rather ditch the notifications entirely than stop other threads; > >I'll keep the notification code out of the FSF tree until we can figure > >out a generally acceptable way to pass asynchronous status > >notifications back to the client. I really don't see the problem with > >my suggestion, though. > > Hmm, I think you're trying to combine several disjoint features into a > single mechanism. > > Feature #1 is notify GDB of [remote] thread create/delete events. > Feature #2 is allow some [remote] threads to continue running while > others (just current?) have stopped. > > >Heck, if I can work out a way to do it safely, I intend to do > >one-thread-stopped-only SVR4 shared library support also. I've heard > >that starting apache2 (multithreaded, and with all modules as DSOs) > >takes several minutes instead of the second or two that it takes > >without GDB attached. > > Yes, feature #2 above. I don't know how generally useful feature #2 is (although it's certainly useful internally). The question becomes whether core GDB needs to know that some threads are still running, or if we can get by without that. Informing core GDB of this fact is beyond me. I'd appreciate any comments on the Hs issue; I'm just going to leave the notification packets out of the first submission of this code, since they are controversial. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer