From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9954 invoked by alias); 6 Sep 2007 17:34:52 -0000 Received: (qmail 9943 invoked by uid 22791); 6 Sep 2007 17:34:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 17:34:42 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 220E610CF6B4 for ; Thu, 6 Sep 2007 10:34:41 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 00C6B28087 for ; Thu, 6 Sep 2007 10:34:41 -0700 (PDT) X-AuditID: 1180711d-a33b7bb000000b5e-c6-46e03a306406 Received: from gdbrulez.apple.com (gdbrulez.apple.com [17.201.22.244]) by relay13.apple.com (Apple SCV relay) with ESMTP id D6A3A28085 for ; Thu, 6 Sep 2007 10:34:40 -0700 (PDT) Message-Id: <9B94A61F-90AD-426F-BD4D-B8ED6B9A5AF4@apple.com> From: Jim Ingham To: GDB List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.903) Mime-Version: 1.0 (Apple Message framework v903) Subject: Re: MI: "^running" issues Date: Thu, 06 Sep 2007 18:08:00 -0000 References: <200709041653.22357.ghost@cs.msu.su> <18142.15716.179444.106490@kahikatea.snap.net.nz> <200709050938.45290.ghost@cs.msu.su> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00053.txt.bz2 We got the asynchronous mode working for the Mac OS X target in the Apple gdb sources. It definitely took a bunch of work beyond what is in the current FSF sources to get all the details working (things like breakpoint commands that restart the target and command files and some other bits like that needed attending to...) It wasn't deadly hard to do, though. We use it mostly so that Xcode can query the target's state at any point - basically a backstop when it looks like maybe the UI and gdb have gotten out of sync. That way you can always unambiguously get the tri-state answer - the target's stopped; the target's running; gdb's gone south. This is actually pretty useful to have around, though in a perfect world would not be necessary... We also use -exec-interrupt. It's certainly true that you can achieve the same thing by sending ^C to the target, but it's much more regular to do everything you're doing with the target through the same control channel. And of course, this moves to gdb the knowledge of any funniness with interrupting a running program - which is where it belongs. Another stronger reason why async was originally done was the experience of merging gdb with Tcl/Tk for the Insight debugger. One of the big reasons for the instability of that project is that when the target is running, gdb is blocked, so if you want to service other events - like window system events in the case of Insight - you've got no good way to do that. We ended up having to run a timer and try to service events in the timer interrupt - a dubious practice at best. It's possible to run the interpreter in a separate thread, and let it and gdb communicate through some side channel. But most interpreters have some mechanism for handling events, and it is much cleaner to have gdb be just another event source. I'm not sure that the current gdb event mechanism is clean enough for easy incorporation with 's event loop now. But that just means there's more design work to do. I still think this is a pretty worthwhile goal. Jim On Sep 5, 2007, at 11:41 AM, Vladimir Prus wrote: > Eli Zaretskii wrote: > >>> From: Vladimir Prus >>> Date: Wed, 5 Sep 2007 09:38:45 +0400 >>> Cc: gdb@sources.redhat.com >>> >>>>> - Killing the idea of async commands. It does not seem to be >>>>> very >>>>> useful >>>>> at this point, so we might be better off ripping it and >>>>> implementing >>>>> afresh later, when it's understood what they should be. >>>> >>>> I'm working in the opposite direction: trying to get GDB to work >>>> asynchronously. I don't see the point of ripping out what is >>>> already >>>> there. >>> >>> Then, can you please provide a specification of what >>> "asynchronously" >>> means, and why it's good for users and frontends? >> >> Asynchronous execution means that some GDB commands can be run while >> GDB waits for the target to stop. It is good for users because you >> can do something useful while you wait for the target to stop. > > Unfortunately, I never saw more concrete details. What commands are > actually > meaningful to emit while target are running and are those commands > of big > enough value to user to warrant extensive coding? Can interested > parties document > those commands at GDB Wiki, or even in email? > > - Volodya > >