gdbserver assert error on arm platform

Message ID 20230511062001.2745878-1-zhiyong.yan@windriver.com
State New
Headers
Series gdbserver assert error on arm platform |

Commit Message

Yan, Zhiyong May 11, 2023, 6:20 a.m. UTC
  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(-)
  

Comments

Kevin Buettner May 11, 2023, 9:04 p.m. UTC | #1
I have some formatting nits as well as a request for a test case.  See
below...

On Thu, 11 May 2023 14:20:01 +0800
<zhiyong.yan@windriver.com> wrote:

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

In addition to the provided patch, could you also add a test case?

> 
> LINK: https://sourceware.org/bugzilla/show_bug.cgi?id=30387

s/LINK/Bug/

> 
> 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){

Missing space before left paren and after right paren.

> +	    /*
> +	    * If resume_step is required by GDB, install single-step breakpoint.
> +	    */

Format the above comment as:

/* If resume_step is required by GDB, install single-step breakpoint.  */

If you want to use a block comment, don't prefix each line with a '*'. Also,
the trailing '*/' should be placed at the end of the last line in the block
comment.  Likewise for the leading '/*'.

> +	    if (supports_software_single_step())

Missing space before '()'.

> +	       install_software_single_step_breakpoints (lwp);
> +	}
> +  }
>  
>    thread->last_status.set_ignore ();
>    lwp->resume = NULL;
> -- 
> 2.25.1
>
  
Yan, Zhiyong June 19, 2023, 1:50 a.m. UTC | #2
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
  
Guinevere Larsen June 20, 2023, 7:35 a.m. UTC | #3
Hi Zhiyong,

Kevin has posted a review back in may 11th: 
https://inbox.sourceware.org/gdb-patches/20230511140407.0a0977fb@f37-zws-nv/
  
Yan, Zhiyong June 20, 2023, 8:08 a.m. UTC | #4
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
>
  
Kevin Buettner June 22, 2023, 1:44 a.m. UTC | #5
Hi Zhiyong,

If possible, it'd be nice if you could write a test case which would
run when a developer does "make check" (with suitable RUNTESTFLAGS and
--target_board settings).  I'd guess that you'd put your new .exp
file and source file into gdb/testsuite/gdb.server.  If you look around
in that directory (and perhaps in some of the other testing directories
too) you might find something similar upon which to base your new
test.

I know from experience that it's sometimes a hassle to write these
test cases, but they're extremely useful in the long term because
regression testing will show if/when the bug (or some other) crops up
again.

Here are a couple of links which might help you to rework your existing
test into a test case for GDB:

Testing GDB:
https://sourceware.org/gdb/wiki/TestingGDB

GDB Testcase Cookbook:
https://sourceware.org/gdb/wiki/GDBTestcaseCookbook

Please also note that I commented on some formatting nits.  Please
address those too.  If you're wondering about GDB's coding conventions,
please see:

https://sourceware.org/gdb/wiki/ContributionChecklist#Properly_Formatted_Changes

Kevin

On Tue, 20 Jun 2023 08:08:52 +0000
"Yan, Zhiyong" <Zhiyong.Yan@windriver.com> wrote:

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

Patch

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;