Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: Questions about GDB-MI Interface
@ 2002-04-24 13:01 chanskw
  2002-04-24 21:55 ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: chanskw @ 2002-04-24 13:01 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb

Thank you.  I will definitely look at Apple's solution to this problem.

Just to clarify things a bit, will GDB continue to support CLI in MI-mode,
even after the complete set of mi-commands are implemented?  Statements
regarding not supporting CLI in MI and its eventual removal are no longer
valid?

In GDB's User's Guide:

     This mechanism is provided as an aid to developers of GDB/MI
     clients and not as a reliable interface into the CLI.

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

Before we decide to go down the path of switching to MI, we need to confirm
that CLI-in-MI capability will continue to be available for us to provide a
console window for our users.

Regards,
Samantha Chan




                                                                                                          
                    Andrew Cagney                                                                         
                    <ac131313@cygn       To:     Samantha Chan/Toronto/IBM@IBMCA                          
                    us.com>              cc:     gdb@sources.redhat.com                                   
                                         Subject:     Re: Questions about GDB-MI Interface                
                    04/24/2002                                                                            
                    10:55 AM                                                                              
                    Please respond                                                                        
                    to Andrew                                                                             
                    Cagney                                                                                
                                                                                                          
                                                                                                          




> 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.

Can I encourage you to look at Apple's contributed code. See:
ftp://sources.redhat.com/pub/gdb/contrib/apple/
As was noted by JimI, they came up with a way to address the problem.

You could even consider extracting the relevant changes from the patch.
  However, before doing this, you would need to establish a GDB
copyright assignment/disclaimer.

With regard to annotations and using GDB's CLI directly, I really would
discourage this.  They are both largely untested(1) and make your code
reliant on the behavour of the underlying CLI (something you can assume
will change).

Andrew

(1) Some what ironically, it was the MI developers that added the
annotation tests to GDB.





^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Questions about GDB-MI Interface
@ 2002-04-25  9:25 chanskw
  0 siblings, 0 replies; 9+ messages in thread
From: chanskw @ 2002-04-25  9:25 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: Eli Zaretskii, gdb

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                                                                         
                    <ac131313@cygn       To:     Eli Zaretskii <eliz@is.elta.co.il>                       
                    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





^ permalink raw reply	[flat|nested] 9+ messages in thread
* Questions about GDB-MI Interface
@ 2002-04-23 10:36 chanskw
  2002-04-24  7:55 ` Andrew Cagney
  0 siblings, 1 reply; 9+ messages in thread
From: chanskw @ 2002-04-23 10:36 UTC (permalink / raw)
  To: gdb

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



^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-04-25 18:59 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-24 13:01 Questions about GDB-MI Interface chanskw
2002-04-24 21:55 ` Eli Zaretskii
2002-04-25  6:41   ` Andrew Cagney
2002-04-25  7:05     ` Eli Zaretskii
2002-04-25  7:41       ` Andrew Cagney
2002-04-25 11:59         ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2002-04-25  9:25 chanskw
2002-04-23 10:36 chanskw
2002-04-24  7:55 ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox