From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24918 invoked by alias); 12 Mar 2005 10:23:16 -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 24862 invoked from network); 12 Mar 2005 10:23:10 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 12 Mar 2005 10:23:10 -0000 Received: from zaretski (tony03-42-6.inter.net.il [80.230.42.6]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id DXM75488 (AUTH halo1); Sat, 12 Mar 2005 12:22:12 +0200 (IST) Date: Sat, 12 Mar 2005 10:23:00 -0000 From: "Eli Zaretskii" To: Nick Roberts Message-ID: <01c526ed$Blat.v2.4$2b933720@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: drow@false.org, dave.korn@artimi.com, kostik@ispras.ru, gdb@sources.redhat.com In-reply-to: <16946.4725.343793.980977@farnswood.snap.net.nz> (message from Nick Roberts on Sat, 12 Mar 2005 10:49:41 +1300) Subject: Re: MI output command error Reply-to: Eli Zaretskii References: <16946.1979.617105.196894@farnswood.snap.net.nz> <20050311213042.GA14428@nevyn.them.org> <16946.4725.343793.980977@farnswood.snap.net.nz> X-SW-Source: 2005-03/txt/msg00134.txt.bz2 > From: Nick Roberts > Date: Sat, 12 Mar 2005 10:49:41 +1300 > Cc: Dave Korn , > Karganov Konstantin , GDB > > > Lack of implementation. No one's done the work. > > Thats understandable. 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. > 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. 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. 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 ;-).