Questions about GDB-MI Interface

[chanskw at ca dot ibm dot com]

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=2 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=2 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 mechanism is provided as an aid to developers of GDB/MI
     clients and not as a reliable interface into the CLI.

The second is a comment in mi/mi-main.c, where the CLI command forwarding
is done, that says

     /* A CLI command was read from the input stream */
     /* This will be removed as soon as we have a complete set of
     mi commands */

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 <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 <cli command> will continue to work as before, providing
a "hybrid of unsupported mi and cli output".  With "-cli-command
<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 = 0 - no pausing at the end of a page
   - set width = 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="725",file="main.c"
Can you suggest an alternative for us to obtain the source of the debugee
under MI?

Thank you

Regards,
Samantha Chan