Re: gdb/mi, new-ui. the console and determining when GDB is ready for the next command

[Jonah Graham <jonah@kichwacoders.com>]

Hi Bob,

Robert Rossi <bob@brasko.net> wrote:
>
> The question I have is, how are people determining when GDB is ready for
> the next
> command when using the new-ui feature of GDB?
> Are people parsing the CLI window for (gdb)?
> Am I missing something obvious?
>

Eclipse CDT uses gdb for the backend debugger, and it does not actually use
the (gdb) prompt except to establish initial connection with gdb. After
that Eclipse tracks state of gdb to know when it can send commands. So in
your example, CDT looks for messages such as *stopped to know when gdb is
stopped and can accept commands. In non-stop mode you further track the
running threads to know which you can communicate with. For MI commands CDT
sends, it knows when they are done by tracking their ^done messages, it
also sends multiple commands at a time before waiting for answers.

> In this case also there is no gdb prompt.

This happens in the reverse case too, when MI issues a step or similar the
CLI terminal does not get a new (gdb) prompt.

> Is this expected behavior or an oversight?

I am used to this behaviour, but I can't comment on whether it is expected
or not, e.g I can type cont<enter> even though no fresh (gdb) prompt:

(gdb)
Breakpoint 5, main () at ../src/helloworld.c:26
26              printf("&x=%p\n", &x);
cont
Continuing.
[Inferior 1 (process 15248) exited normally]
(gdb)

HTH
Jonah