public inbox for
 help / color / mirror / Atom feed
From: Adrian Oltean <>
To: "" <>
Subject: Semihosting in GDB 11.1 | Proposed patch for interrupting in sync mode
Date: Mon, 7 Mar 2022 19:39:40 +0000	[thread overview]
Message-ID: <> (raw)

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)

   /* 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))

   /* 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,

             reply	other threads:[~2022-03-07 19:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 19:39 Adrian Oltean [this message]
2022-03-08 22:10 ` Tom Tromey
2022-03-09  7:25 Adrian Oltean
2022-03-09 19:49 ` Tom Tromey
2022-03-10  9:47   ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).