This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Questions about GDB-MI Interface
- From: chanskw at ca dot ibm dot com
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Eli Zaretskii <eliz at is dot elta dot co dot il>, gdb at sources dot redhat dot com
- Date: Thu, 25 Apr 2002 12:23:13 -0400
- Subject: Re: Questions about GDB-MI Interface
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