Hi Bruno,
     The test case is attached into https://sourceware.org/bugzilla/show_bug.cgi?id=30387. Please look for "Luis Machado 2023-05-02 14:17:40 UTC" in Bugzilla comments, you can see Luis already produced this issue.
     I copy Produce step below, test app and gdb script can be found in the attachment.

Produce step (This issue can only be produced on arm platform):

(1) tar xvf gdbserver-test-app.tar on a host which can do arm-cross compile.
(2) In osm.service, modify ExecStart path according to your running environment.
(3) make
(4) Please refer to "make install", install osm systemd service on target board.

[On target board]
systemctl daemon-reload
systemctl start osm
gdbserver --debug --debug-format=all --remote-debug --event-loop-debug --once --attach :1234 $(pgrep osm)

[On pc host]
your-arm-gdb ./osm(this is test app build out as above)  -x ~/gdbx2

gdbx2 can be found in the attachment, please modify target-remote pointing to your  target board's gdbserver in gdbx2.

When gdb executes gdbx2, gdbserver will assert on target board.
     

-----Original Message-----
From: Bruno Larsen <blarsen@redhat.com> 
Sent: Tuesday, June 20, 2023 3:36 PM
To: Yan, Zhiyong <Zhiyong.Yan@windriver.com>; gdb-patches@sourceware.org
Cc: tom@tromey.com
Subject: Re: [PATCH] [patch] gdbserver assert error on arm platform

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Zhiyong,

Kevin has posted a review back in may 11th:
https://inbox.sourceware.org/gdb-patches/20230511140407.0a0977fb@f37-zws-nv/

--
Cheers,
Bruno

On 19/06/2023 03:50, Yan, Zhiyong wrote:
> Hi,
>      Did this patch get a chance of review ?
>
> Thanks!
> Zhiyong
>
>
>
> -----Original Message-----
> From: zhiyong.yan@windriver.com <zhiyong.yan@windriver.com>
> Sent: Thursday, May 11, 2023 2:20 PM
> To: gdb-patches@sourceware.org
> Cc: tom@tromey.com; Yan, Zhiyong <Zhiyong.Yan@windriver.com>
> Subject: [PATCH] [patch] gdbserver assert error on arm platform
>
> From: Zhiyong Yan <zhiyong.yan@windriver.com>
>
> Bugzilla 30387 has given the steps of producing this issue on arm platform.
> Gdb should not assume pending threads always generate “a non-gdbserver trap event”, a “Signal 17” event could happen.
> Now that resume_stopped_resumed_lwps() -> may_hw_step() assumes that the break point must already exist, resume_one_thread() should ensure the software breaking point is installed although the thread is pending.
>
> LINK: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
>
> Signed-off-by: Zhiyong Yan zhiyong.yan@windriver.com
> ---
>   gdbserver/linux-low.cc | 12 ++++++++++--
>   1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc index e6a39202a98..543daf66376 100644
> --- a/gdbserver/linux-low.cc
> +++ b/gdbserver/linux-low.cc
> @@ -4670,8 +4670,16 @@ linux_process_target::resume_one_thread (thread_info *thread,
>
>         proceed_one_lwp (thread, NULL);
>       }
> -  else
> -    threads_debug_printf ("leaving LWP %ld stopped", lwpid_of (thread));
> +  else{
> +     threads_debug_printf ("leaving LWP %ld stopped", lwpid_of (thread));
> +     if(thread->last_resume_kind == resume_step){
> +         /*
> +         * If resume_step is required by GDB, install single-step breakpoint.
> +         */
> +         if (supports_software_single_step())
> +            install_software_single_step_breakpoints (lwp);
> +     }
> +  }
>
>     thread->last_status.set_ignore ();
>     lwp->resume = NULL;
> --
> 2.25.1
>