[cdt-debug-dev] Questions to be posted to GDB Mailing List regarding MI

[chanskw@xxxxxxxxxx]

Hi,

We are in the process of investigating the possibility of switching GDBPicl
to use GDB's MI interface instead of annotations.
During this investigation, we have identified some problems with using MI
in GDBPicl.
We are not sure how to solve some of the problems.  So, we drafted a list
of questions to be posted onto GDB Mailing List
and hope to gain some insights from the GDB experts on the mailing list.

Before we post these questions, we would like to receive some feedback from
you.
Please review the questions and let me know if you have any additional
comments or concerns.

I plan to post these questions by next Tuesday, April 23.
Please respond by next Monday, April 22.

Thanks,
Samantha Chan



=======================================

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.

   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?

   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?

   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-*?

   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 kill it
      - "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?

   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?

   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?