[
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
|
>
> 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:
>
That's good. The thing I've noticed is that even if there is a
need for having CLI to satisfy some folks. They still want the
response to be reflected in the UI not merely to have back the
block of text in the console. For many users moving to get to the
mouse is annoying, but typing "next" and see the little registers
Icon updated is .. nirvana.
> 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
>
>
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
--
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!
