From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27945 invoked by alias); 23 Apr 2002 17:36:17 -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 27938 invoked from network); 23 Apr 2002 17:36:16 -0000 Received: from unknown (HELO e32.co.us.ibm.com) (32.97.110.130) by sources.redhat.com with SMTP; 23 Apr 2002 17:36:16 -0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3NHaAXk017042 for ; Tue, 23 Apr 2002 13:36:10 -0400 Received: from d25ml02.torolab.ibm.com (d25ml02.torolab.ibm.com [9.26.6.103]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3NHYrL67626 for ; Tue, 23 Apr 2002 11:34:53 -0600 Subject: Questions about GDB-MI Interface To: gdb@sources.redhat.com Message-ID: From: chanskw@ca.ibm.com Date: Tue, 23 Apr 2002 10:36:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-SW-Source: 2002-04/txt/msg00394.txt.bz2 We are working on a debugger plugin for the Eclipse project (www.eclipse.org) that layers a GUI over gdb. We've had reasonable success using annotate=3D2 for this, but have received a lot of suggestions that we should switch to MI. The output stream separation MI provides is by itself enough to make switching attractive, but we also see some problems we aren't sure how to deal with, and hoped we could get some answers from the experts. 1. Like many others, our debugger provides the user with a console window to enter CLI commands to access Gdb function not available through the GUI. One of the reasons we initially chose annotate=3D2 was that you can dynamically switch between annotate and non-annotate, and this let us provide authentic CLI in this window. That dynamic switching is not possible with MI, but as noted in GDB documentation CLI commands can still be used in MI mode. That would seem to be a solution, except we are unsure how to interpret two statements. One is the User Guide statement that This=A0mechanism=A0is=A0provided=A0as=A0an=A0aid=A0to=A0developers=A0o= f=A0GDB/MI clients=A0and=A0not=A0as=A0a=A0reliable=A0interface=A0into=A0the=A0CLI. The second is a comment in mi/mi-main.c, where the CLI command forwarding is done, that says /*=A0A=A0CLI=A0command=A0was=A0read=A0from=A0the=A0input=A0stream=A0*/ /*=A0This=A0will=A0be=A0removed=A0as=A0soon=A0as=A0we=A0have=A0a=A0com= plete=A0set=A0of =A0=A0=A0=A0=A0mi=A0commands=A0*/ At face value these make us wonder about the intent and future of the CLI-in-MI capability. Will there be a long-term reliable solution to this, or is it expected that MI-based debuggers will expose all function through their UIs and not rely on CLI, or is it something else? 2. On the same topic, when we use CLI-in-MI we see that we sometimes get pure CLI output, sometimes pure MI output, and sometimes a mixture of both. The Users Guide hints that this is normal, when it says to expect an "unsupported hybrid of GDB/MI and CLI output", but we don't know if we can provide a reliable and high-fidelity console window under these conditions. Do you have any suggestions how we should proceed, or how other front ends have dealt with this? Ideally, we'd like to let our users continue to use the CLI, and see CLI-style output, while our GUI simultaneously interacts with gdb using MI. So we'd like to change the definition of MI to support this, and have all commands change their output style based on whether they are invoked via the CLI or MI. We found one of the recent discussions from GDB Mailing List addressing this specific problem: http://sources.redhat.com/ml/gdb/2002-04/msg00348.html Apple has implemented a solution to allow front-ends to switch GDB's interpreter between MI and CLI. This solution will allow frontend to relay commands entered by user to GDB, and responses coming back from GDB will be in CLI-style. CLI-style responses can be sent back to our console window and will be meaningful to users. Inspired by this proposal, we would like to make the following suggestions to enhance GDB for console window support in UI: As noted in GDB User's Guide and Mailing List, MI responses are sometimes needed for CLI commands because not all functions have equivalent MI implementation. MI responses are needed in order to provide those missing functionality through CLI commands in MI mode. Therefore, we realize that providing straight mapping of MI command with MI-style output and CLI command with CLI-style output may not be a viable solution. We need to be able to tell GDB the style of output that we are expecting to get out of a CLI command. As a suggestion, gdb could provide a MI command for submitting CLI command. It could be something like the following: -cli-command Entering this command tells the MI interpreter that this is really a CLI command and CLI output is expected from this command. In addition to getting CLI output, we also would like to get MI output and MI event notifications (e.g. breakpoint state changes, display state changes) after a CLI command. With MI output and notifications, our program will no longer need to parse CLI-style responses. Our program can correctly determine the different states of a debug session based on pure MI responses. Furthermore, having MI event notifications available, updating our GUI does not require us to query all the possible states of a debug session and calculating the differences after a CLI command. In summary, plain will continue to work as before, providing a "hybrid of unsupported mi and cli output". With "-cli-command ", we expect to get CLI output, MI output and MI event notifications about state changes. Please let us know what you think about this suggestion. 3. None of the documented MI -display-* functions are implemented, but "variable objects" provides similar function. Are the -var-* commands the long term favorites over -display-*? 4. Outside of the console view, we use other CLI commands today that do not have implemented MI equivalents. We expect we would have to continue using these CLI commands and parse CLI output as before until MI supports the rest of the missing functions. Listed is the set of CLI commands currently used that do not have MI equivalents: - "info program" - to find inferior's PID so we can interrupt a running program - "jump" - for jump to location (in source and disassembly view) - "info signals" - for handling signals and exception filtering - "handle" - for handling signals and exception filtering - "set height" - set to 0 so that GDB does not pause during output no matter how long the output is - "set width" - set to 0 so that GDB does not wrap its output - "set print elements 0" - set to 0 to ensure that all elements in a large array are printed out - "set print null-stop" - stops printing the characters of an array when the first NULL is encountered, for variables presentation - "set stop-on-solib-events" - for deferred and load breakpoints - "whatis" / "ptype" - "info line" - for converting source line to address - "info line *" - for converting address to source line - "maintenance print objfiles" - to discover file/module correspondence - "info source" - "info sharedlibrary" Is this the right strategy to take? or do you have other suggestions regarding how we can obtain these missing function? 5. As noted in the list above, we use a few settings to ensure that GDB provides continuous output without user interactions. - set height =3D 0 - no pausing at the end of a page - set width =3D 0 - output does not wrap Since GDB is controlled by our wrapper through a pipe, would GDB be able to recognize that input is originated from a pipe instead of regular command line? Do we still need these settings? 6. Sometimes Gdb can find source better than our source locator. In this case, GUI relies on GDB to give us the source of the debugee. This is done by using the "list" CLI command. This command does not have an equivalent MI implementation, and using this CLI command under MI does not display the source file. Instead, it returns the following output: &"list\n" ^done,line=3D"725",file=3D"main.c" Can you suggest an alternative for us to obtain the source of the debugee under MI? Thank you Regards, Samantha Chan