[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] Questions to be posted to GDB Mailing List regarding MI - comments?
|
In addition getting CLI output after a CLI command, we would also like to
see MI output and notification events after a CLI command. Here's a
rewrite of what we are going to add to the question 2:
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.
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.
What do you think about this addition?
Regards,
Samantha
Samantha
Chan/Toronto/IBM@IBMC To: cdt-debug-dev@xxxxxxxxxxx
A cc:
Sent by: Subject: Re: [cdt-debug-dev] Questions to be posted to GDB
cdt-debug-dev-admin@e Mailing List regarding MI - comments?
clipse.org
04/22/2002 11:50 AM
Please respond to
cdt-debug-dev
Tom,
Thank you very much for your response.
Tom > The one major comment I have is that I think this would be improved
if
Tom > you said what you would like gdb to do. For instance, something
like:
Tom > We'd like to let our users continue to use the CLI, and see
CLI-style
Tom > output, while our GUI simultaneously interacts with gdb using MI.
So
Tom > we'd like to change the definition of MI to support this, and have
all
Tom > commands change their output style based on whether they are
invoked
Tom > via the CLI or MI.
Tom > What do you think of that?
I think this is a great suggestion. It summarizes what we want and what we
want to achieve.
I will add them at the end of question 2.
Samantha> - "info program" - to find inferior's PID so we can kill it
Tom > That's interesting. Does `kill' not do what you want?
I should rephrase it to:
"info program" - to find inferior's PID so we can interrupt it.
We really want to interrupt the program instead of killing the program.
We need the program id so that we can send it a SIGINT signal outside
of gdb while the program is running in a loop. "kill" or "interrupt"
does not really do the job here since we cannot submit any command
to gdb when the program is running.
Tom > There are some fairly recent long threads about this sort of thing on
Tom > the gdb list. Look for information about the GVD GUI, which got
Tom > confused due to gdb's (new) habit of using realpath on file names.
Thanks. I will look for this thread of discussion and see if I can get
anything out
of it.
Regards,
Samantha
Tom Tromey
<tromey@xxxxxxxxxx> To:
cdt-debug-dev@xxxxxxxxxxx
Sent by: cc:
cdt-debug-dev-admin@e Subject: Re:
[cdt-debug-dev] Questions to be posted to GDB
clipse.org Mailing List regarding MI
- comments?
04/19/2002 09:04 PM
Please respond to
cdt-debug-dev
>>>>> "Samantha" == chanskw <chanskw@xxxxxxxxxx> writes:
Samantha> Before we post these questions, we would like to receive
Samantha> some feedback from you. Please review the questions and let
Samantha> me know if you have any additional comments or concerns.
I think this document is fine. I do have a comment and a question,
but they are pretty minor and just for my own edification.
The one major comment I have is that I think this would be improved if
you said what you would like gdb to do. For instance, something like:
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.
What do you think of that?
Samantha> - "info program" - to find inferior's PID so we can kill it
That's interesting. Does `kill' not do what you want?
Samantha> Can you suggest an alternative for us to obtain the source
Samantha> of the debugee under MI?
There are some fairly recent long threads about this sort of thing on
the gdb list. Look for information about the GVD GUI, which got
confused due to gdb's (new) habit of using realpath on file names.
Tom
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
