From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4356 invoked by alias); 11 Mar 2005 11:32:45 -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 3326 invoked from network); 11 Mar 2005 11:32:01 -0000 Received: from unknown (HELO pluton.ispras.ru) (83.149.199.253) by sourceware.org with SMTP; 11 Mar 2005 11:32:01 -0000 Received: (qmail 35135 invoked from network); 11 Mar 2005 11:27:54 -0000 Received: from unknown (HELO truba.ispras.ru) (83.149.198.41) by pluton.ispras.ru with SMTP; 11 Mar 2005 11:27:54 -0000 Received: from truba.ispras.ru (root@localhost) by truba.ispras.ru (8.13.1/8.13.1) with SMTP id j2BBRGAO029579 for ; Fri, 11 Mar 2005 14:27:16 +0300 Received: from ispserv.ispras.ru (ispserv [83.149.198.72]) by truba.ispras.ru (8.13.1/8.13.1) with ESMTP id j2BBRGGd029569; Fri, 11 Mar 2005 14:27:16 +0300 Received: from kite.ispras.ru (kite.ispras.ru [83.149.198.52]) by ispserv.ispras.ru (8.12.8/8.12.8) with ESMTP id j2BBPQDA030385; Fri, 11 Mar 2005 14:25:29 +0300 Date: Fri, 11 Mar 2005 11:32:00 -0000 From: Konstantin Karganov Reply-To: Konstantin Karganov Organization: ISP RAS Message-ID: <14615837483.20050311143539@ispras.ru> To: "'GDB'" CC: "'Bob Rossi'" Subject: Re[2]: MI output command error In-reply-To: <20050310170318.GD14061@white> References: <20050310163329.GA15132@nevyn.them.org> <20050310170318.GD14061@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release SMTP-Filter Version 2.0.0 [0125], KAS/Release X-Spamtest-Info: Pass through X-SW-Source: 2005-03/txt/msg00123.txt.bz2 Hello Bob, > Now I have a whole slew of questions that I need the answer to, this > could probably go right up on the doco under, FE FAQ. > What is the intention of the -async flag as it relates to GDB/MI? > What problem does it solve(why is it needed)? > Are MI FE developers supposed to be using the -async flag? In fact, there are 2 basic models of inferior exectuion control: synchronous and asynchronous. Consider the example of step command: - Synchronous step means that you issue a command and wait for its completion. The most wonderful things here is that you always know the state of the debuggee, you know when and where it started and stopped its execution and when the step has finished, the state of the inferior is fixed and you can analyze it. The problem appears if the step has blocked (i.e. at endless loop or communication) - you need to interrupt the inferior and try to dig out the cause of the problem. - Asynchronous step means that as you issue a command the debuggee starts to execute and at the same time you get the control and can issue other commands. The interface doesn't block and always remain responsive, but the problems are clear - you don't see the state of the inferior, since it is changing and can't get what's going on there, you don't know when the step has finished, you can't probably issue some commands (i.e. set variable). For human operating a debugger the synchronous model looks more natural and usable - s/he issues commands sequentially and always keeps track of what is going on inside. For the GUI wrapper, on the contrary, asynchronous model seems to be preferrable - GUI is an asynchronous thing and it is expected to display information even if the execution is in progress. The question is - what you can display during the inferior execution and does it make sense (because the process state is changing quickly). My first posts to this list were exactly on the (a)synchronous gdb mode and the possible commands during the inferior execution. In practice it turned out that gdb behaves synchronously (gdb 5.0 accepts the -async option, but it doesn't affect anything when debugging local target, and gdb 6.3 refuses to recognize -async switch). That is not a severe problem if you can interrupt the execution, display what needed and then continue preforming previous command, but in gdb you can't interrupt the execution (in synchronous mode there is no sence in issuing -exec-interrupt, sinse gdb doesn't listen for commands) and sending SIGINT from another terminal doesn't help (why??) and also there is no documented way to continue the interrupted execution transparently. So, the -async flag could solve some problems, but here is one problem - it doesn't work itself. And also another unclear point - how to interrupt the execution and restore from the interrupt (assumed that the gdb is controlled by other application through the pipe or socket). It is not crucial for the user operating the debugger, but for implementing a FE some functions of the kind would be appreciated... -- Best regards, Konstantin