Semihosting in GDB 11.1 | Proposed patch for interrupting in sync mode

Hi everyone,

I'm currently in the process of upgrading to GDB 11.1 (from GDB 7.11.1) in
a product that's based on Eclipse CDT, GDB client and on a proprietary GDB server
implementation. I'd appreciate some feedback/comments with regards to
the following two topics described below:

1. I need to run GDB client in all-stop mode with target-async set to off.
This seems to be a must in order to make some python scripts (containing
gdb.post_event('continue')) interact correctly with Eclipse CDT and with
some automation I have around the python scripts. Long story short, I patched
GDB client with the changes below in order to be able to interrupt the target
after posting a 'continue' event via python API. On a first round of testing,
everything looks fine but I'd like to know if there's any chance I'll break
any use case with these changes.

---
gdb/target.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gdb/target.c b/gdb/target.c
index 7875289819..d2516705ca 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -1,6 +1,6 @@
/* Select target systems and architectures at runtime for GDB.

-   Copyright (C) 1990-2021 Free Software Foundation, Inc.
+   Copyright (C) 1990-2022 Free Software Foundation, Inc.

    Contributed by Cygnus Support.

@@ -937,7 +937,7 @@ target_terminal::inferior (void)

   /* A background resume (``run&'') should leave GDB in control of the
      terminal.  */
-  if (ui->prompt_state != PROMPT_BLOCKED)
+  if (target_is_async_p () && ui->prompt_state != PROMPT_BLOCKED)
     return;

   /* Since we always run the inferior in the main console (unless "set
@@ -974,7 +974,7 @@ target_terminal::restore_inferior (void)
   struct ui *ui = current_ui;

   /* See target_terminal::inferior().  */
-  if (ui->prompt_state != PROMPT_BLOCKED || ui != main_ui)
+  if (target_is_async_p () &&  (ui->prompt_state != PROMPT_BLOCKED || ui != main_ui))
     return;

   /* Restore the terminal settings of inferiors that were in the
--

2. File I/O (semihosting) when a multicore (ARMv8) target is involved seems
to exhibit an issue. My multicore debugging model assumes that each core is a
separate thread. If I have 'printf' calls executed on separate cores, I noticed
that the messages are duplicated on secondary cores (other than core 0). The
remote log snippet that highlights the root cause is pasted below. Long story
short, the 'H' packet that is sent to the server and instructs it to use
thread 0 for some further operations, actually causes troubles because breakpoint
handling and run control gets broken afterwards. Note that the 'Fwrite' is the
result of a 'printf' on a secondary core, thus instructing the server to use
thread 0 breaks lots of things inside the GDB server. The 'H' packet seems to
be sent as a result of the 'continue' action and it translates into a call to
'switch_to_no_thread'. If I ignore the 'H' packet, semihosting breakpoints and run
control are correctly handled, so the second 'Fwrite' RSP sequence would not
exist (this is the expected behavior). Is the described behavior a known issue
inside GDB? Or do I have to change something in the server to correct the
described behavior?

[remote] Sending packet: $vCont;c#a8
[remote] Received Ack
[remote] wait: enter
  [remote] Packet received: Fwrite,1,80026300,12
  [remote] Sending packet: $Hg0#df
  [remote] Received Ack
  [remote] Packet received: OK
  [remote] Sending packet: $m80026300,12#8f
  [remote] Received Ack
  [remote] Packet received: 48656c6c6f2066726f6d20436f726523370a
  [remote] Sending packet: $F12#a9
  [remote] Received Ack
  [remote] Packet received: Fwrite,1,80026300,12
  [remote] Sending packet: $m80026300,12#8f
  [remote] Received Ack
  [remote] Packet received: 48656c6c6f2066726f6d20436f726523370a
  [remote] Sending packet: $F12#a9
  [remote] Received Ack
  [remote] Packet received: T05thread:p1.8;core:7;
[remote] wait: exit

Thank you for any comments,
Adrian