There is a case that when debugging a program using gdb mi， if a command got an error and throw_error back to function"start_event_loop", the error message has been displayed, but prompt "(gdb)" is not displayed. Actually, command line can get input now，"(gdb)" is displayed when the next command done. But this state is not right, some IDEs can not get the state of program now. A way to reproducing this case： resources: 1. an a.out with debug-info 2. a gdb_debug with debug-info 3. a gdbserver 4. a gdb step: 1. run gdbserver :112233 a.out 2. gdb --args ./gdb_debug a.out --inter mi b remote_wait (or remote_target::wait) run 3. come to gdb_debug: tar rem:112233 4. come to gdb: continue 5. come to gdb_debug: singlestep 6. come to gdb: b readchar (or remote_target::readchar) continue 7. ps -A | grep gdbserver kill -9 pid_of_gdbserver 8. come to gdb: break event-loop.c:380 (380 for gdb8.2, in function "start_event_loop", after "CATCH" operation, where function async_enable_stdin() wrote.) continue Result: when gdb_debug back to "start_event_loop, event-loop.c:380", you can remove all breakpoints, and come to gdb doing continue: At this time, connection for gdbserver is lost, gdb_debug print the correspond message too, but prompt "(gdb)" is not outputed event if “current_ui->prompt_state = PROMPT_NEEDED” has been written in function “start_event_loop”.
I ran across this as well. I sent this patch, but no comments yet https://sourceware.org/pipermail/gdb-patches/2022-January/184881.html
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
Fixed.