From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9483 invoked by alias); 7 Sep 2005 06:55:27 -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 9458 invoked by uid 22791); 7 Sep 2005 06:55:23 -0000 Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 07 Sep 2005 06:55:23 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ECtor-0007bU-RQ for gdb@sources.redhat.com; Wed, 07 Sep 2005 08:54:05 +0200 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Sep 2005 08:54:05 +0200 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Sep 2005 08:54:05 +0200 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: The 'x' command: size problem Date: Wed, 07 Sep 2005 06:55:00 -0000 Message-ID: References: <20050906152448.GA2444@nevyn.them.org> <200509061935.12549.ghost@cs.msu.su> <20050906154249.GA3270@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 X-SW-Source: 2005-09/txt/msg00045.txt.bz2 Daniel Jacobowitz wrote: > On Tue, Sep 06, 2005 at 07:35:12PM +0400, Vladimir Prus wrote: >> No, it's not very hard. But given anynchronious nature of communication >> with gdb I'm trying to limit the number of queries to minimum, to >> minimize the amount of data I have to keep. > > The MI data stream is basically synchronous. Sure, there are > asynchronous notifications in it. But a synchronous reply always > corresponds to the previously implemented synchronous command, doesn't > it? It's serialized, so if you have a lot of different threads wanting > to bang away at GDB, sure you're going to need some bookkeeping. By "asynchronous" I mean that after sending a command to gdb, I can't just immediately get the result. I need to return to Qt message loop and wait why gdb reply is sent to my object. So, instead of: unsigned size = gdb_eval("sizeof(g)"); I need to add another method to my class that will be called when result of "sizeof" arrives, and this complicates the implementation quite a bit. >> > > And it'll give you a whole new host of issues keeping up with the > changing interface. But at least (assuming the interface is a nice C++ one), something like: get_memory(std::vector& c) is crystal clear, while documentation of MI's -data-read-memory output format is very unclear. It does not document what's "table", or "next page" is and does not link to any definitions of those terms. > And GDB does some fairly complicated things using > signals and wait, which can yield very surprising behavior if you're > running it in the same context as your GUI. Can't comment on this. > I don't see how it would eliminate the need for asynchronous > interfaces, either. I'd be talking with gdb in a separate thread. At least in Qt4, it will be possible to send requests from GUI thread to debugger controller thread, fully transparently. For Qt3, I'd implement such across-threads-command-queue myself. - Volodya