[Bug mi/23820] No one handle "current_ui->prompt_state = PROMPT_NEEDED"

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e8b4efc3cf3d5d2c475b3e5c31439aa5bcd277ae

commit e8b4efc3cf3d5d2c475b3e5c31439aa5bcd277ae
Author: Tom Tromey <tromey@adacore.com>
Date:   Thu Jan 6 08:42:49 2022 -0700

    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

-- 
You are receiving this mail because:
You are on the CC list for the bug.