From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15692 invoked by alias); 25 Apr 2002 16:25:51 -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 15256 invoked from network); 25 Apr 2002 16:24:31 -0000 Received: from unknown (HELO e33.esmtp.ibm.com) (32.97.110.131) by sources.redhat.com with SMTP; 25 Apr 2002 16:24:31 -0000 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id g3PGOEWQ078656; Thu, 25 Apr 2002 12:24:16 -0400 Received: from d25ml02.torolab.ibm.com (d25ml02.torolab.ibm.com [9.26.6.103]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3PGNNs201550; Thu, 25 Apr 2002 10:23:23 -0600 Subject: Re: Questions about GDB-MI Interface To: Andrew Cagney Cc: Eli Zaretskii , gdb@sources.redhat.com Message-ID: From: chanskw@ca.ibm.com Date: Thu, 25 Apr 2002 09:25:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00437.txt.bz2 I think Apple's solution is a good start for solving this CLI-in-MI problem. Allowing frontends to switch interfaces dynamically will ensure that we can provide consistent CLI-style responses to users if needed to. However, the CLI-style responses provided may not be sufficient for console window support in a GUI. The intention of providing CLI interface in MI is to allow frontend to provide console window for user to interact with GDB directly. Two things need to be updated after such commands are entered in the console window. Firstly, the console window needs to print out GDB's responses in user-readable format. This goal can be achieved by Apple's solution by dynamically switching the interpreter. Secondly, all the information displayed in GUI needs to be updated as well. To achieve this goal, frontends will need to query all the possible states of a debug session, which could be time consuming and hard to do. A more elegant solution would be providing MI-style responses and state change notifications along with CLI-style responses after a CLI command is entered. In this case, UI does not need to parse any CLI-style responses resulted from the CLI command. It can solely rely on MI-responses. Providing state change notifications, like breakpoint add/delete, allows UI to know what has been changed, and all the queries for different state changes are no longer needed. I do not know GDB internals enough to know if this is possible to do. Any comments about this? One thing that I am still confused about, if CLI commands are not supposed to be used in MI mode and MI does not yet have the complete set of GDB functionality, how are we supposed to get the missing functionality? How do other frontends deal with this problem now? Regards, Samantha Chan Andrew Cagney us.com> cc: Samantha Chan/Toronto/IBM@IBMCA, gdb@sources.redhat.com Subject: Re: Questions about GDB-MI Interface 04/25/2002 10:41 AM Please respond to Andrew Cagney > On Thu, 25 Apr 2002, Andrew Cagney wrote: > > >> It was added with much hesitation because there was real concern that >> once a vaguely looking console mechanism was added, people would try to >> use it instead of investing the time and resources needed to address the >> problem of implementing a real console interface. > > > What was envisioned as a solution for the problem at hand, namely, that > any decent front-end to GDB must allow the user to type CLI commands? My best answer is that it was envisioned to be fixed in 2.0. Several alternatives were suggested but no decision was made. Apple has has since, kind of, made the decision by comming up with a working solution. Of the alternatives I remember: - properly wrap the CLI up in an MI command (what apple did). Has problems with query() where the CLI wants to prompt back to the user. (apple's solution) - separate out the CLI from GDB and have it as a separate MI client - not have a CLI enjoy, Andrew