Print MI prompt on interrupted command

Joel noticed that if the remote dies unexpectedly during a command --
you can simulate this by using "continue" and then killing gdbserver
-- then the CLI will print a new prompt, but MI will not.  Later, we
found out that this was also filed in bugzilla as PR mi/23820.

The output looks something like this:

    | (gdb)
    | cont
    | &"cont\n"
    | ~"Continuing.\n"
    | ^running
    | *running,thread-id="all"
    | (gdb)
    | [... some output from GDB during program startup...]
    | =thread-exited,id="1",group-id="i1"
    | =thread-group-exited,id="i1"
    | &"Remote connection closed\n"

Now, what about that "(gdb)" in the middle?

That prompt comes from this questionable code in
mi-interp.c:mi_on_resume_1:

      /* This is what gdb used to do historically -- printing prompt
	 even if it cannot actually accept any input.  This will be
	 surely removed for MI3, and may be removed even earlier.  */
      if (current_ui->prompt_state == PROMPT_BLOCKED)
	fputs_unfiltered ("(gdb) \n", mi->raw_stdout);

... which seems like something to remove.  But maybe the intent here
is that this prompt is sufficient, and MI clients must be ready to
handle output coming after a prompt.  On the other hand, if this code
*is* removed, then nothing would print a prompt in this scenario.

Anyway, the CLI and the TUI handle emitting the prompt here by hooking
into gdb::observers::command_error, but MI doesn't install an observer
here.

This patch adds the missing observer and arranges to show the MI
prompt.  Regression tested on x86-64 Fedora 34.

It seems like this area could be improved a bit, by having
start_event_loop call the prompt-displaying code directly, rather than
indirecting through an observer.  However, I haven't done this.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820

0 files changed, 0 insertions, 0 deletions