GDB/MI questions

Marc Khouzam
Thu Jan 19 14:31:00 GMT 2017

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


More information about the Gdb mailing list