From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3125 invoked by alias); 7 Sep 2005 13:42:43 -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 2956 invoked by uid 22791); 7 Sep 2005 13:42:16 -0000 Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 07 Sep 2005 13:42:16 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1ED0Bo-0007lD-Ck for gdb@sources.redhat.com; Wed, 07 Sep 2005 17:42:13 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1ED0Bo-0007l8-At for gdb@sources.redhat.com; Wed, 07 Sep 2005 17:42:12 +0400 From: Vladimir Prus To: gdb@sources.redhat.com Subject: Re: The 'x' command: size problem Date: Wed, 07 Sep 2005 13:42:00 -0000 User-Agent: KMail/1.7.2 References: <20050907131319.GA2963@nevyn.them.org> In-Reply-To: <20050907131319.GA2963@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509071742.11727.ghost@cs.msu.su> X-SW-Source: 2005-09/txt/msg00051.txt.bz2 On Wednesday 07 September 2005 17:13, Daniel Jacobowitz wrote: > On Wed, Sep 07, 2005 at 10:53:34AM +0400, Vladimir Prus wrote: > > 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. > > This is a problem people have solved a thousand times... Yes, and I've solved it too today, so that gives 1001 times. But the solution is not pretty, and if 'x' allowed expression in both parameters I would not need it. The same issue is in MI: -data-read-memory &i b 1 1 sizeof(i) does not work, while -data-read-memory &i x 1 1 4 works fine. Is it's hard to evaluate 'num-column' argument as expression? And BTW, docs don't even mention this restriction in MI. > > > 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. > > Please, then, feel free to improve the documentation. Oh.. if only it were in Docbook :-( Besides, how can I improve documentation if I don't know definitions of those terms, to begin with? > Really, a C++ > interface would be just as complicated. Even in your example. Where > would you get the memory from? How much would you get? Ok, the real interface would be: void get_memory(unsigned address, unsigned amount_in_bytes, vector& result) > What would it do on errors? Well, though a type defined from gdb_exception. I think think the above prototype is clearer, and much shorter that documentation for -data-read-memory, that does not even documents everything. > > > 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. > > Then you're going to need to asynchronously wait for the gdb thread to > return data to your GUI thread. If you're willing to block waiting for > that, then block waiting for GDB to print output! No, I don't think that's needed. Say, user ask for a value of variable. GUI thread invokes a method in gdb controller thread (across thread boundary). The gdb controller gets all the necessary data by synchnonious calls to gdb library and when done, does cross-thread call to GUI thread, saying "add var foo with value 10" to the list of variables. No need to block anything. - Volodya