Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Marc Khouzam <marc.khouzam@ericsson.com>
To: Bob Rossi <bob@brasko.net>, "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: GDB/MI questions
Date: Thu, 19 Jan 2017 14:31:00 -0000	[thread overview]
Message-ID: <DB4PR07MB0656CEBBCC14BB061FB319B6F57E0@DB4PR07MB0656.eurprd07.prod.outlook.com> (raw)
In-Reply-To: <20170119031445.GA24616@xubuntu.brasko.net>

> Hi,
> 
> I'm attempting to convert CGDB (a GDB front end) from annotations to MI.
> Two questions I've run up against:
> 
> The first is, with annotations, it's easy to tell when GDB can except
> another command, just wait for the prompt annotation.
> With GDB/MI it seems a little trickier. So far I have this:
>     Wait for the gdb prompt
>     If you have not recieved a *running yet, it's safe to run a command.
>     Otherwise, if you have recieved a *running, you need to wait for
>     the prompt and for *stopped.
> Anyone have a better approach? Does multi target impact this?

In most cases, you don't need to care about this.  You can normally
send other commands even when GDB is blocked and they will be
buffered until GDB unblocks.

Same goes for the prompt, you don't need to wait for it; you can just
send your commands and they will be processed when GDB is ready.
Eclipse never waits for the prompt.

Are you running mi-async?  I recommend doing that.  It implies that
GDB will always be accepting commands even while the inferior is
running.  Some commands may fail, such as looking at memory or
doing an -exec-next on a thread that is running, and you should be
prepared for that, but it is not a big deal.  One of the advantages is 
that you can execute some other commands such as 'info os', listing
threads, changing GDB's configuration, etc.

With mi-async, there are some cases when you need to wait for the 
*stopped event.  For example, enabling 'record' can only be done when
the inferior is stopped, so sending an -exec-interrupt followed by 
'interpreter-exec console record' is too quick and will fail; instead you
must send the -exec-interrupt, wait for *stopped, then enable record.
But the majority of cases don't need to wait.
 
> Second, from the CLI if you run the command "next", then if you hit
> the enter key, GDB will run the "next" command again.
> However, in GDB/MI if you run -interpreter-exec console "next", and then
> follow that with the Enter key, GDB does nothing.
> Is there a way to run the last command?

I don't believe MI supports that.  But that feature is really a console feature,
I don't see why you'd want that in MI.  I assume you don't expect your
user to type MI commands manually, so I don't see why they would 
need to repeat.

But if you really want that for some reason, you can just keep track
of the last command you sent in MI, and then when getting an lone
Enter, you could send it again.  But then you don't have the smarts
of GDB to know which commands should repeat and which should not.
I don't think this is a very good idea.

I hope this helps.

Marc
    




       reply	other threads:[~2017-01-19 14:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170119031445.GA24616@xubuntu.brasko.net>
2017-01-19 14:31 ` Marc Khouzam [this message]
2017-01-19 14:52   ` Bob Rossi
2017-01-19 15:06     ` Pedro Alves
2017-01-19 15:11   ` Bob Rossi
2017-01-19 15:24     ` Marc Khouzam
2017-01-19 15:40       ` Jan Vrany
2017-01-19 16:17         ` Pedro Alves
2017-01-19 15:47     ` Simon Marchi
2017-01-19 16:03       ` Bob Rossi
2017-01-19 16:15         ` Simon Marchi
2017-01-19 16:27           ` Bob Rossi
2017-01-19 16:33             ` Pedro Alves
2017-01-19 14:43 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB4PR07MB0656CEBBCC14BB061FB319B6F57E0@DB4PR07MB0656.eurprd07.prod.outlook.com \
    --to=marc.khouzam@ericsson.com \
    --cc=bob@brasko.net \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox