From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4903 invoked by alias); 3 Oct 2005 20:31:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4892 invoked by uid 22791); 3 Oct 2005 20:31:10 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 03 Oct 2005 20:31:10 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EMWxo-00045N-5r; Mon, 03 Oct 2005 16:31:08 -0400 Date: Mon, 03 Oct 2005 20:31:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20051003203108.GA15652@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17142.56731.941946.838268@farnswood.snap.net.nz> <20050808130516.GA9046@nevyn.them.org> <17160.63891.324530.937796@farnswood.snap.net.nz> <430B9BF8.500@apple.com> <17188.60739.749026.738477@farnswood.snap.net.nz> <17198.37622.443418.520082@farnswood.snap.net.nz> <17216.38283.618507.704220@kahikatea.snap.net.nz> <20051003131829.GA19106@nevyn.them.org> <17217.34460.753468.405145@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17217.34460.753468.405145@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00026.txt.bz2 On Tue, Oct 04, 2005 at 08:29:32AM +1300, Nick Roberts wrote: > Daniel Jacobowitz writes: > > Sorry, miscommunication. You don't need approval to create a branch; > > go right ahead. > > OK. Thanks. > > > I violently dislike the idea of linking gdb with pthreads. I'm > > confident that we can get the benefits without that, however. I've got > > this patch sitting in my queue of things to play with. > > I know this will sound stupid but what is the alternative? Using fork? Doing it "asynchronously" through the GDB event loop, which is I believe the same way we handle remote async targets. All in one process. This is a little more complicated to design, however, it's got less complexity at runtime. I've spent enough of my life using GDB on systems where pthreads didn't work that I don't want to make GDB dependent on them. -- Daniel Jacobowitz CodeSourcery, LLC