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

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

[Adrian Oltean]

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

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

[Tom Tromey]

>>>>> Adrian Oltean via Gdb <gdb@sourceware.org> writes:

> 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.

I think it would be better on the whole to figure out a way to make this
work with target-async.  In the long run I'd prefer that gdb remove sync
target wait entirely -- that the default be target-async everywhere.

> but I'd like to know if there's any chance I'll break
> any use case with these changes.

I don't have the answer to that I'm afraid.

> 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: $Hg0#df

I think this request means to switch to any thread for subsequent
non-continue/step requests.  So, ignoring it is almost the right thing
to do, I think the idea is just to ensure that some stopped thread is
selected.

Tom

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

[Pedro Alves]

On 2022-03-09 19:49, Tom Tromey wrote:
> Adrian> Unfortunately, I could not find ways to adapt all the other components I have around GDB to 
> Adrian> work with target-async mode enabled. It is what it is...
> 
> I'm a little lost about this, because my mental model is that target
> async shouldn't really change anything.  I think it is just an
> implementation detail about where gdb waits for events -- is it in
> wait() or in select()?
> 
> So, it would be interesting to learn what the differences are.  Perhaps
> this can be patched up.
> 
> Adrian> Regarding the 'H' packet, I had a second look in the RSP specs
> Adrian> where it's stated that '0' indicates an arbitrary
> Adrian> process/thread. So, as you mentioned, I changed the GDB server
> Adrian> code to simply ensure there's a valid thread stopped marked as
> Adrian> 'current'. The original implementation incorrectly assimilated
> Adrian> '0' with 'first thread' (always).
> 
> I'm a little surprised this matters as well, but anyway I think it's
> fine to submit a patch like this.  Maybe others have some idea of what's
> going on.

I'm not sure that I get what Adrian is callilng "first thread", but I take
it to mean that the server was numbering threads starting at "0".
But, in the RSP, you can't use '0' as thread id, as it has a special meaning.
I.e., if the server is numbering threads like, 0,1,2,3,... then it will
run into problems, because when GDB says "Hg0", it doesn't mean "select
the first thread, the one with id "0".  The typical fix is to just start
numbering threads at 1 instead of 0, for example.

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

[Tom Tromey]

Adrian> Unfortunately, I could not find ways to adapt all the other components I have around GDB to 
Adrian> work with target-async mode enabled. It is what it is...

I'm a little lost about this, because my mental model is that target
async shouldn't really change anything.  I think it is just an
implementation detail about where gdb waits for events -- is it in
wait() or in select()?

So, it would be interesting to learn what the differences are.  Perhaps
this can be patched up.

Adrian> Regarding the 'H' packet, I had a second look in the RSP specs
Adrian> where it's stated that '0' indicates an arbitrary
Adrian> process/thread. So, as you mentioned, I changed the GDB server
Adrian> code to simply ensure there's a valid thread stopped marked as
Adrian> 'current'. The original implementation incorrectly assimilated
Adrian> '0' with 'first thread' (always).

I'm a little surprised this matters as well, but anyway I think it's
fine to submit a patch like this.  Maybe others have some idea of what's
going on.

Tom

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

[Adrian Oltean]

Hi Tom,

Unfortunately, I could not find ways to adapt all the other components I have around GDB to 
work with target-async mode enabled. It is what it is...

Regarding the 'H' packet, I had a second look in the RSP specs where it's stated that '0' indicates
an arbitrary process/thread. So, as you mentioned, I changed the GDB server code to simply
ensure there's a valid thread stopped marked as 'current'. The original implementation incorrectly
assimilated '0' with 'first thread' (always).

Thank you,
Adrian

-----Original Message-----
From: Tom Tromey <tom@tromey.com> 
Sent: Wednesday, March 9, 2022 12:10 AM
To: Adrian Oltean via Gdb <gdb@sourceware.org>
Cc: Adrian Oltean <adrian.oltean@nxp.com>
Subject: [EXT] Re: Semihosting in GDB 11.1 | Proposed patch for interrupting in sync mode

Caution: EXT Email

>>>>> Adrian Oltean via Gdb <gdb@sourceware.org> writes:

> 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.

I think it would be better on the whole to figure out a way to make this work with target-async.  In the long run I'd prefer that gdb remove sync target wait entirely -- that the default be target-async everywhere.

> but I'd like to know if there's any chance I'll break any use case 
> with these changes.

I don't have the answer to that I'm afraid.

> 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: $Hg0#df

I think this request means to switch to any thread for subsequent non-continue/step requests.  So, ignoring it is almost the right thing to do, I think the idea is just to ensure that some stopped thread is selected.

Tom