From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21549 invoked by alias); 13 Mar 2005 09:36:50 -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 21513 invoked from network); 13 Mar 2005 09:36:43 -0000 Received: from unknown (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org with SMTP; 13 Mar 2005 09:36:43 -0000 Received: from farnswood.snap.net.nz (p171-tnt2.snap.net.nz [202.124.108.171]) by viper.snap.net.nz (Postfix) with ESMTP id 6AC12498C1D; Sun, 13 Mar 2005 22:36:39 +1300 (NZDT) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 467AB62FBE; Sun, 13 Mar 2005 09:35:03 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16948.2374.864364.458035@farnswood.snap.net.nz> Date: Sun, 13 Mar 2005 09:36:00 -0000 To: Eli Zaretskii Cc: drow@false.org, dave.korn@artimi.com, kostik@ispras.ru, gdb@sources.redhat.com Subject: Re: MI output command error In-Reply-To: <01c526ed$Blat.v2.4$2b933720@zahav.net.il> References: <16946.1979.617105.196894@farnswood.snap.net.nz> <20050311213042.GA14428@nevyn.them.org> <16946.4725.343793.980977@farnswood.snap.net.nz> <01c526ed$Blat.v2.4$2b933720@zahav.net.il> X-SW-Source: 2005-03/txt/msg00143.txt.bz2 > > ... However, given that MI was introduced in GDB 5.0, I think there > > should be something in the manual explaining this as it seems to create a > > lot of confusion. It needs to be written by someone who understands the > > issue i.e not myself. > > I'm all for documenting this in some useful way, but I fail to see how > could this be done. Describing the async operation itself is already > a big challenge, as the details are extremely confusing, unless you've > read the code several times and have a good understanding of the > underlying system calls (like `poll' and `select'). Differences > between interpreters add another dimension of complexity to this. Well for someone to be able to code it must mean that it can be documented. But if you mean that those who did the coding are no longer available to do the documenting, then I can see this would be a difficult task. > > I believe that operation is asynchronous with certain targets, > > although I have never managed to create these conditions, even with > > gdbserver over TCP. > > Actually, I think that the asynchronous operation is independent of > the target. The infrastructure for this is in event-loop.c, which is > not specific to any target. With gdbserver over TCP, on the host machine you can use e.g 1) target async localhost:1234 instead of 2) target remote localhost:1234 and GDB behaves slightly differently Using CLI, "cont &" gives: Asynchronous execution not supported on this target. with 2) and Continuing. with 1). However the inferior doesn't actually seem to continue execution as it normally would and issuing a further command (that need not be about the state of execution gives someting like: (gdb) info target Cannot execute this command while the target is running. Using MI: -target-select remote localhost:1234 ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]} (gdb) 111-exec-continue 111^running (gdb) -exec-interrupt The MI command -exec-interrupt does not reach GDB -target-select async localhost:1234 ^connected,thread-id="0",frame={addr="0x400012e0",func="??",args=[]} (gdb) 111-exec-continue 111^running (gdb) -exec-interrupt ^done (gdb) -exec-continue ^error,msg="Cannot execute command exec-continue while target running" (gdb) The MI command -exec-interrupt is acknowledged but again the inferior doesn't actually seem to continue execution and GDB seems to think the target is still running So it look like the asynchronous operation has been partially implemented. > The problem with implementing async operation with the CLI interface > is, AFAIU, not its dependence on some target-specific feature, but > rather the need to redesig the CLI front end to do something useful > while waiting for a prolonged operation to run to completion. For GUI > front ends, such as those who use MI, it's clear what to do during > that time, and the separate-process implementation makes it even > easier to design. By contrast, the CLI interface is part of the GDB > process. Actually if the asynchronous operation was working, I'm not sure what I would do with it. When I debug, I'm used to waiting for execution to stop. The only exception that I can think of is the Etnus debugger, where you can press a key to get a snapshot of the stack during execution. > I don't consider myself a specialist in these matters, so please take > the above with a grain of salt (i.e., it might all be wrong ;-). You know more than I do, and I appreciate you sharing it. Nick