Re: Questions about GDB-MI Interface`

Re: Questions about GDB-MI Interface`

[Jim Ingham]

I think we are in agreement, but just to restate:

First off, we should make a distinction between running a CLI command while
using the MI interpreter, and using the CLI's *_command implementation of
some functionality to get the job done because there is no MI equivalent.

The goal originally was that the MI would not use any of the CLI's *_command
C functions.  If it really needed to, that probably meant that the *_command
function in question should be split off into a CLI bit, which just handled
the arguments, and a function which did all the interesting bits, and then
the mi command for the same functionality would do its argument parsing, and
then run the implementation function.

This is a good goal, it makes the gdb interfaces much cleaner, and not
dependent on the nature of gdb's CLI.  The hack in the MI is that it's
"unknown command" function passes the command to the CLI's execute_command.
This is not a very good way to run CLI commands, as you have found, and not
a good way to structure gdb either.  So I don't think there are any good
arguments for keeping it around, except the we haven't finished the MI
one...

I think that there are also lots of folks who are very used to the gdb CLI,
so supporting routing CLI commands through the MI interpreter is also
important.  But  this function is NOT fulfilled by using the CLI as the
backstop for MI commands....

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

We had to do ALL the things you are attempting to get PB's console window to
work.  As you rightly state, if you can type into the console but it makes
the GUI get out of sync, the console is useless...  For instance, if the
console command causes the target to start running, but the GUI doesn't
notice, you will get out of sync, and probably never get right again...

So, we added an "-mi-interpreter-exec" command that runs commands as if it
were the console interpreter.  The syntax is:

mi-interpreter-exec console <command1> <command2> ...

These will feed the commands one by one to the execute_command function, AND
switch the output printer to the CLI printer, so you see console style
output.  Also, while the CLI command is running, it puts in place a series
of hooks that will report back interesting things to the GUI.  Among other
things, we put hooks into the query mechanism so that if the command that
the user has typed into our console would require user feedback, we can ask
the questions as they would appear on the gdb console.  We also handle the
case where the target gets run out from under the GUI.

As I said, all this works pretty well.  The only caveat with this
implementation is that we run gdb in async mode for all the targets that we
support.  I haven't tested this code in the synchronous case, and it seems
possible that you will have to juke stuff around a bit to get it working in
that case.
> 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?
> 

This is a theoretical "not supposed to be used" thing.  When needed we grit
our teeth and call through.  Actually, whenever our GUI guy ends up needing
a CLI command with no MI equivalent, he comes and bugs me, and I usually add
the MI version...  So if you look in our MI code, you will see some more
functions that we have added, though there are still many more to go...

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              jingham@apple.com
Developer Tools - gdb

Re: Questions about GDB-MI Interface`

[Eli Zaretskii]

> Date: Thu, 25 Apr 2002 12:23:17 -0700
> From: Jim Ingham <jingham@apple.com>
> 
> So, we added an "-mi-interpreter-exec" command that runs commands as if it
> were the console interpreter.  The syntax is:
> 
> mi-interpreter-exec console <command1> <command2> ...
> 
> These will feed the commands one by one to the execute_command function, AND
> switch the output printer to the CLI printer, so you see console style
> output.  Also, while the CLI command is running, it puts in place a series
> of hooks that will report back interesting things to the GUI.

Isn't it better to have the CLI-style output be followed by the
MI-style output, with some clear separator between them?  The front
end could then filter the CLI output to the display, while keeping
the MI output for itself, to sync itself with the debugger.

> > 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?
> 
> This is a theoretical "not supposed to be used" thing.  When needed we grit
> our teeth and call through.  Actually, whenever our GUI guy ends up needing
> a CLI command with no MI equivalent, he comes and bugs me, and I usually add
> the MI version...  So if you look in our MI code, you will see some more
> functions that we have added, though there are still many more to go...

Nevertheless, the CLI support is required, I think, because the user
of the GUI should be able to type CLI commands directly.  The GUI
front end will never be as flexible as GDB command and scripting
language, even if all the commands are supported in the MI.

Re: Questions about GDB-MI Interface`

[Andrew Cagney]

> Date: Thu, 25 Apr 2002 12:23:17 -0700
>> From: Jim Ingham <jingham@apple.com>
>> 
>> So, we added an "-mi-interpreter-exec" command that runs commands as if it
>> were the console interpreter.  The syntax is:
>> 
>> mi-interpreter-exec console <command1> <command2> ...
>> 
>> These will feed the commands one by one to the execute_command function, AND
>> switch the output printer to the CLI printer, so you see console style
>> output.  Also, while the CLI command is running, it puts in place a series
>> of hooks that will report back interesting things to the GUI.
> 
> 
> Isn't it better to have the CLI-style output be followed by the
> MI-style output, with some clear separator between them?  The front
> end could then filter the CLI output to the display, while keeping
> the MI output for itself, to sync itself with the debugger.

I suspect the details would be like this.  There would also be a bit of 
pragmatism though.  To do this ``right'', GDB needs control over all 
output. That in turn means eliminating all those remaining printf's. 
Hmm, Pierre is quietly doing this!

enjoy,
Andrew

Re: Questions about GDB-MI Interface`

[Jim Ingham]

On 4/26/02 12:54 AM, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

>> Date: Thu, 25 Apr 2002 12:23:17 -0700
>> From: Jim Ingham <jingham@apple.com>
>> 
>> So, we added an "-mi-interpreter-exec" command that runs commands as if it
>> were the console interpreter.  The syntax is:
>> 
>> mi-interpreter-exec console <command1> <command2> ...
>> 
>> These will feed the commands one by one to the execute_command function, AND
>> switch the output printer to the CLI printer, so you see console style
>> output.  Also, while the CLI command is running, it puts in place a series
>> of hooks that will report back interesting things to the GUI.
> 
> Isn't it better to have the CLI-style output be followed by the
> MI-style output, with some clear separator between them?  The front
> end could then filter the CLI output to the display, while keeping
> the MI output for itself, to sync itself with the debugger.

Yes, this is the way that we do it.  After all, the intepreter-exec command
is an MI command, so I just accumulate the hook results in the result of the
MI command, and send them all when it is done.  This works great in the
async case, because even if you start the inferior you get an immediate
"done" for the command, with all the hook results as well.  I think this
will have to be worked on a bit in the synchronous case, so that you send
some out-of-band MI message.  Though it has a few of its own problems, the
Async stuff makes this sort of thing MUCH easier!!

> 
>>> 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?
>> 
>> This is a theoretical "not supposed to be used" thing.  When needed we grit
>> our teeth and call through.  Actually, whenever our GUI guy ends up needing
>> a CLI command with no MI equivalent, he comes and bugs me, and I usually add
>> the MI version...  So if you look in our MI code, you will see some more
>> functions that we have added, though there are still many more to go...
> 
> Nevertheless, the CLI support is required, I think, because the user
> of the GUI should be able to type CLI commands directly.  The GUI
> front end will never be as flexible as GDB command and scripting
> language, even if all the commands are supported in the MI.
> 

-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              jingham@apple.com
Developer Tools - gdb

Re: Questions about GDB-MI Interface`

[Andrew Cagney]

> 
> Yes, this is the way that we do it.  After all, the intepreter-exec command
> is an MI command, so I just accumulate the hook results in the result of the
> MI command, and send them all when it is done.  This works great in the
> async case, because even if you start the inferior you get an immediate
> "done" for the command, with all the hook results as well.  I think this
> will have to be worked on a bit in the synchronous case, so that you send
> some out-of-band MI message.  Though it has a few of its own problems, the
> Async stuff makes this sort of thing MUCH easier!!

Another, er, one of those, er, ``overriding objectives'' is ment to be 
converting all natives to async mode.  I'm not exactly following this 
one through with much vigor though (I'm having too much fun just keeping 
multi-arch at bay :-).

However, the positive is that we've now got native async code to refer to.

enjoy,
Andrew

Re: Questions about GDB-MI Interface`

[Jim Ingham]

Andrew,

Yeah, there were a bunch of things I had to fix to get this to work (getting
breakpoint commands that continue the target not to fall over, for instance,
was a bit of a trick).  But it seems pretty solid now.  The only major thing
I have to fix is restructuring the startup sequence so that "run" commands
issued in the .gdbinit file work...

Most of the trouble that remains on our side is the result of the odd
interplay between Mach and BSD in Mac OS X.

This is another of the bits that we need to find time to disentangle from
everything else and submit.  Oh for those extra 5 or 6 hours per day!

Jim

>> 
>> Yes, this is the way that we do it.  After all, the intepreter-exec command
>> is an MI command, so I just accumulate the hook results in the result of the
>> MI command, and send them all when it is done.  This works great in the
>> async case, because even if you start the inferior you get an immediate
>> "done" for the command, with all the hook results as well.  I think this
>> will have to be worked on a bit in the synchronous case, so that you send
>> some out-of-band MI message.  Though it has a few of its own problems, the
>> Async stuff makes this sort of thing MUCH easier!!
> 
> Another, er, one of those, er, ``overriding objectives'' is ment to be
> converting all natives to async mode.  I'm not exactly following this
> one through with much vigor though (I'm having too much fun just keeping
> multi-arch at bay :-).
> 
> However, the positive is that we've now got native async code to refer to.
> 
> enjoy,
> Andrew
> 
> 

-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              jingham@apple.com
Developer Tools - gdb