From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19605 invoked by alias); 2 May 2002 20:13:31 -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 19579 invoked from network); 2 May 2002 20:13:29 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 2 May 2002 20:13:29 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4251D3D88; Thu, 2 May 2002 16:13:31 -0400 (EDT) Message-ID: <3CD19DEB.2010803@cygnus.com> Date: Thu, 02 May 2002 13:13: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> <3CD15D5A.7020308@cygnus.com> <20020502155203.GA12647@nevyn.them.org> <3CD16BC9.2010209@cygnus.com> <20020502191411.GB19130@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00019.txt.bz2 > On Thu, May 02, 2002 at 12:39:37PM -0400, Andrew Cagney wrote: > >> I'm fairly sure that the archives have plenty of info on the ``O'' >> packet and why/how it should be replaced. One thread is ``gdb/remote - >> I/O''. > > > Ah, I've found the thread. I see that there was a rough consensus > (among just about everyone but J.T. Conklin, who I believe was remote > maintainer at the time?) about the disadvantages of asynchronous Joint. I think the consensus was that the advantages of a more robust mechanism (some will laugh at the very suggestion that the GDB protocol is even vaguely robust :-) outway the disadvantages of having the protocol synchronous. > replies. However, I'd like to add another point of view. At one level I agree with you completly, unfortunatly the remote protocol, as it stands, just don't work that way :-( The ``O'' packet while ``a good idea at the time'' (sarcasm) just doesn't cut it when it comes to providing something that is reliable. > 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. > 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. enjoy, Andrew