[gdb] Fix handling of aborted inferior call

PR gdb/33069 reports the following behavior:
...
$ gdb -q ls -ex starti -ex "b *1"
Reading symbols from ls...
(No debugging symbols found in ls)
Starting program: /usr/bin/ls

Program stopped.
0x00007ffff7fe4f00 in _start () from /lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x1
(gdb) p (int)strlen("abc")
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1

Command aborted.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(malloc@plt) will be abandoned.
When the function is done executing, GDB will silently stop.

[1]+  Stopped                 gdb -q ls -ex starti -ex "b *1"
$ fg
gdb -q ls -ex starti -ex "b *1"
(gdb)
...
with gdb being unresponsive to further input.

PR gdb/33068 reports a similar problem, but using gdbserver, and in that case
gdb doesn't go into the background, but is likewise unresponsive.

This is a regression since commit b1c0ab20809 ("gdb: avoid double stop after
failed breakpoint condition check"), and consequently since release gdb 14.1.

The commit changed this in run_inferior_call:
...
   if (current_ui->prompt_state == PROMPT_BLOCKED)
-    current_ui->unregister_file_handler ();
-  else
-    current_ui->register_file_handler ();
+    {
+      if (call_thread->thread_fsm ()->finished_p ())
+	async_disable_stdin ();
+      else
+	async_enable_stdin ();
+    }
...
which means current_ui->register_file_handler is no longer called in the
current_ui->prompt_state == PROMPT_NEEDED case.

Fix this by:
- restoring this behavior, fixing the unresponsiveness, and
- adding target_terminal::ours alongside it, fixing the problem that gdb goes
  into the background.

Add a new test-case gdb.base/infcall-failure-2.exp, a regression test for the
unresponsiveness issue.  The problem of gdb going into the background did not
reproduce in the test-case.

Tested on x86_64-linux.

Reviewed-By: Keith Seitz <keiths@redhat.com>

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

0 files changed, 0 insertions, 0 deletions