From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29906 invoked by alias); 3 Oct 2005 21:59:16 -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 29897 invoked by uid 22791); 3 Oct 2005 21:59:14 -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 21:59:14 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EMYKz-0004q0-Tp; Mon, 03 Oct 2005 17:59:10 -0400 Date: Mon, 03 Oct 2005 21:59:00 -0000 From: Daniel Jacobowitz To: Jim Ingham Cc: Stan Shebs , Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20051003215909.GA18458@nevyn.them.org> Mail-Followup-To: Jim Ingham , Stan Shebs , Nick Roberts , gdb-patches@sources.redhat.com References: <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> <20051003203108.GA15652@nevyn.them.org> <4341A4B4.8000601@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00031.txt.bz2 On Mon, Oct 03, 2005 at 02:50:27PM -0700, Jim Ingham wrote: > This isn't just Mac OS X. Any ptrace based system that wants to > write a real async target is going to have to spawn a thread > somewhere to do it, since ptrace is a blocking call. That's wrong. First of all, ptrace never blocks. Second of all, ptrace returns events through wait4, which generates SIGCHLD. All very amenable to handling in select(). > This isn't so bad, though. If the platform doesn't have a reliable > pthreads implementation, it won't get a flakey gdb, rather, it just > won't get an async native target. Well, I'd rather only have one set of targets than maintain both... if we can make the target loop fully asynchronous, then we should do that. Otherwise one code path is absolutely promised to bit-rot. As an aside, it's not so much a question of a reliable pthreads implementation, as being able to use GDB to debug the pthreads implementation. -- Daniel Jacobowitz CodeSourcery, LLC