From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25332 invoked by alias); 3 Oct 2005 21:50:56 -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 25313 invoked by uid 22791); 3 Oct 2005 21:50:54 -0000 Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 03 Oct 2005 21:50:54 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j93LoJRc027956; Mon, 3 Oct 2005 14:50:19 -0700 (PDT) Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay5.apple.com (Apple SCV relay) with ESMTP id 73FA132401B; Mon, 3 Oct 2005 14:50:16 -0700 (PDT) In-Reply-To: <4341A4B4.8000601@apple.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> <20051003203108.GA15652@nevyn.them.org> <4341A4B4.8000601@apple.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Daniel Jacobowitz , Nick Roberts , gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: RFC: MI output during program execution Date: Mon, 03 Oct 2005 21:50:00 -0000 To: Stan Shebs X-SW-Source: 2005-10/txt/msg00030.txt.bz2 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. 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. Jim On Oct 3, 2005, at 2:37 PM, Stan Shebs wrote: > Daniel Jacobowitz wrote: > > >> 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. >> >> > Remote async can do it (more-or-less) portably because both the user > and target interaction happen through file descriptors, and the usual > API supports multiplexing. Darwin is problematic because you have > to get some data from events and the like that only have blocking > calls to monitor, so you need a thread per blocking syscall. > > >> >> 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. >> >> > Ideally you'd push the thread/multiplex decision down into target > code, > but this would be a semi-ambitious rework to event-loop.c. It might > not matter though, if Darwin (and other configs maybe) can keep using > their own thread-hell code, while something like Linux can assume file > descriptors for inferior monitoring and thus use the general > mechanism. > > Stan > >