[PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[Ciaran Woodward]

Rationale/background:
When using schedule-multiple (sched_multi) in gdb, all inferiors
are set to continue when the c command is used. However, before
this patch, only the 'current' inferior would have its
control->stop_soon field cleared. This field causes certain stops
to be ignored, and is only intended for initial attach.

By not clearing this field before continue, continuing with inferior 2
in focus and with inferior 1 hitting the next breakpoint, would cause
gdb to ignore the breakpoint and any attempt to stop the target with
Ctrl-C following that - even though the target was already stopped.
The only fix was to quit GDB and restart.

Solution:
With this patch, all inferiors being resumed have their
control->stop_soon fields cleared, so gdb does not ignore the
breakpoints of any inferior inadvertently.
---
 gdb/infrun.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 543cccc5311..894157ed1d1 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -2808,18 +2808,18 @@ clear_proceed_status (int step)
 	 we're about to resume, implicitly and explicitly.  */
       for (thread_info *tp : all_non_exited_threads (resume_target, resume_ptid))
 	clear_proceed_status_thread (tp);
+
+      for(struct inferior* inferior : all_non_exited_inferiors(resume_target))
+        inferior->control.stop_soon = NO_STOP_QUIETLY;
     }
 
-  if (inferior_ptid != null_ptid)
+  if (non_stop && inferior_ptid != null_ptid)
     {
       struct inferior *inferior;
 
-      if (non_stop)
-	{
-	  /* If in non-stop mode, only delete the per-thread status of
-	     the current thread.  */
-	  clear_proceed_status_thread (inferior_thread ());
-	}
+      /* If in non-stop mode, only delete the per-thread status of
+         the current thread.  */
+      clear_proceed_status_thread (inferior_thread ());
 
       inferior = current_inferior ();
       inferior->control.stop_soon = NO_STOP_QUIETLY;
-- 
2.25.1

Re: [PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[Simon Marchi]

On 2022-07-25 12:22, Ciaran Woodward wrote:
> Rationale/background:
> When using schedule-multiple (sched_multi) in gdb, all inferiors
> are set to continue when the c command is used. However, before
> this patch, only the 'current' inferior would have its
> control->stop_soon field cleared. This field causes certain stops
> to be ignored, and is only intended for initial attach.
> 
> By not clearing this field before continue, continuing with inferior 2
> in focus and with inferior 1 hitting the next breakpoint, would cause
> gdb to ignore the breakpoint and any attempt to stop the target with
> Ctrl-C following that - even though the target was already stopped.
> The only fix was to quit GDB and restart.
> 
> Solution:
> With this patch, all inferiors being resumed have their
> control->stop_soon fields cleared, so gdb does not ignore the
> breakpoints of any inferior inadvertently.

Hi Ciaran,

Can you please provide some reproducing steps?  Some simple test
programs along with the sequence of GDB commands to use.  This way,
we'll be sure we look at the same problem.

Simon

RE: [PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[Ciaran Woodward]

> Can you please provide some reproducing steps?  Some simple test
> programs along with the sequence of GDB commands to use.  This way, we'll
> be sure we look at the same problem.

Hi Simon,

Sure! The way I actually found this was when connected to a stub which
supports the multi process extensions of the remote serial protocol.
I managed to reproduce it using gdbserver on a linux system, but the
procedure is a bit more obscure:

In the case of the stub I am using, the 'processes' are actually hardware
cores, and so they already exist when you first connect to the remote.
In this reproduction, I run gdb twice - once to set up the remote state,
then a second time to connect to multiple processes at the same time, which
is what produces the issue. There may well be a simpler way to do this.

The program to reproduce is simple:

// run.c ---------------
#include <unistd.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
        printf("1\n");
        sleep(2);
        printf("2\n");
        sleep(2);
        printf("3\n");

        while (1)
        {
                sleep(1);
                printf(".");
        }
}
// end run.c -------------

And I compiled it simply with: gcc -g run.c

Then to reproduce:

Run: gdbserver --multi :2331
# leave this running

Run: gdb
target extended-remote :2331
set schedule-multiple off
add-inferior
set remote exec-file ~/test/a.out
file ~/test/a.out
start
infe 2
file ~/test/a.out
start
disconnect
q
# now we have exited this instance of gdb
# gdbserver is still running, with 2 frozen processes

Run: gdb
target extended-remote :2331
# At this point, gdb has recognised both inferiors,
# but only sets the control->stop_soon field to STOP_QUIETLY_REMOTE
# on inferior 2. (which may also be a bug - maybe should be both)
set schedule-multiple on
infe 2
file ~/test/a.out
infe 1
file ~/test/a.out
break run.c:7
break run.c:10
dis 1.2
dis 2.1
c
# At this point, GDB sets the control->stop_soon field to NO_STOP_QUIETLY
# but only on the currently selected inferior (1).
# first breakpoint hit, inferior 1
c
# second break never hit, Ctrl-c also doesn't stop.

Cheers,
Ciaran

[PING] [PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[Ciaran Woodward]

Hi,

Quick ping - this (or something similar) is required for working with multiple inferiors on a remote if you connect to the remote while the inferiors are already running. There is a reproduction description here: https://sourceware.org/pipermail/gdb-patches/2022-July/191092.html

Cheers,
Ciaran

> -----Original Message-----
> From: Ciaran Woodward <ciaranwoodward@xmos.com>
> Sent: 25 July 2022 17:23
> To: gdb-patches@sourceware.org
> Subject: [PATCH] gdb: Fix missing first breakpoint in schedule-multiple
> mode
> 
> Rationale/background:
> When using schedule-multiple (sched_multi) in gdb, all inferiors
> are set to continue when the c command is used. However, before
> this patch, only the 'current' inferior would have its
> control->stop_soon field cleared. This field causes certain stops
> to be ignored, and is only intended for initial attach.
> 
> By not clearing this field before continue, continuing with inferior 2
> in focus and with inferior 1 hitting the next breakpoint, would cause
> gdb to ignore the breakpoint and any attempt to stop the target with
> Ctrl-C following that - even though the target was already stopped.
> The only fix was to quit GDB and restart.
> 
> Solution:
> With this patch, all inferiors being resumed have their
> control->stop_soon fields cleared, so gdb does not ignore the
> breakpoints of any inferior inadvertently.
> ---
>  gdb/infrun.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 543cccc5311..894157ed1d1 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -2808,18 +2808,18 @@ clear_proceed_status (int step)
>  	 we're about to resume, implicitly and explicitly.  */
>        for (thread_info *tp : all_non_exited_threads (resume_target,
> resume_ptid))
>  	clear_proceed_status_thread (tp);
> +
> +      for(struct inferior* inferior :
> all_non_exited_inferiors(resume_target))
> +        inferior->control.stop_soon = NO_STOP_QUIETLY;
>      }
> 
> -  if (inferior_ptid != null_ptid)
> +  if (non_stop && inferior_ptid != null_ptid)
>      {
>        struct inferior *inferior;
> 
> -      if (non_stop)
> -	{
> -	  /* If in non-stop mode, only delete the per-thread status of
> -	     the current thread.  */
> -	  clear_proceed_status_thread (inferior_thread ());
> -	}
> +      /* If in non-stop mode, only delete the per-thread status of
> +         the current thread.  */
> +      clear_proceed_status_thread (inferior_thread ());
> 
>        inferior = current_inferior ();
>        inferior->control.stop_soon = NO_STOP_QUIETLY;
> --
> 2.25.1

[PING 2][PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[Ciaran Woodward]

Hi,

Quick ping - this (or something similar) is required for working with multiple inferiors on a remote if you connect to the remote while the inferiors are already running. There is a reproduction description here: https://sourceware.org/pipermail/gdb-patches/2022-July/191092.html

Cheers,
Ciaran

> -----Original Message-----
> From: Ciaran Woodward <ciaranwoodward@xmos.com>
> Sent: 25 July 2022 17:23
> To: gdb-patches@sourceware.org
> Cc: Ciaran Woodward <ciaranwoodward@xmos.com>
> Subject: [PATCH] gdb: Fix missing first breakpoint in schedule-multiple
> mode
> 
> Rationale/background:
> When using schedule-multiple (sched_multi) in gdb, all inferiors
> are set to continue when the c command is used. However, before
> this patch, only the 'current' inferior would have its
> control->stop_soon field cleared. This field causes certain stops
> to be ignored, and is only intended for initial attach.
> 
> By not clearing this field before continue, continuing with inferior 2
> in focus and with inferior 1 hitting the next breakpoint, would cause
> gdb to ignore the breakpoint and any attempt to stop the target with
> Ctrl-C following that - even though the target was already stopped.
> The only fix was to quit GDB and restart.
> 
> Solution:
> With this patch, all inferiors being resumed have their
> control->stop_soon fields cleared, so gdb does not ignore the
> breakpoints of any inferior inadvertently.
> ---
>  gdb/infrun.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 543cccc5311..894157ed1d1 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -2808,18 +2808,18 @@ clear_proceed_status (int step)
>  	 we're about to resume, implicitly and explicitly.  */
>        for (thread_info *tp : all_non_exited_threads (resume_target,
> resume_ptid))
>  	clear_proceed_status_thread (tp);
> +
> +      for(struct inferior* inferior :
> all_non_exited_inferiors(resume_target))
> +        inferior->control.stop_soon = NO_STOP_QUIETLY;
>      }
> 
> -  if (inferior_ptid != null_ptid)
> +  if (non_stop && inferior_ptid != null_ptid)
>      {
>        struct inferior *inferior;
> 
> -      if (non_stop)
> -	{
> -	  /* If in non-stop mode, only delete the per-thread status of
> -	     the current thread.  */
> -	  clear_proceed_status_thread (inferior_thread ());
> -	}
> +      /* If in non-stop mode, only delete the per-thread status of
> +         the current thread.  */
> +      clear_proceed_status_thread (inferior_thread ());
> 
>        inferior = current_inferior ();
>        inferior->control.stop_soon = NO_STOP_QUIETLY;
> --
> 2.25.1

[PING 3][PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[Ciaran Woodward]

Hi,

Ping 3 - this (or something similar) is required for working with multiple inferiors on a remote if you connect to the remote while the inferiors are already running. There is a reproduction description here: https://sourceware.org/pipermail/gdb-patches/2022-July/191092.html

Cheers,
Ciaran

> -----Original Message-----
> From: Ciaran Woodward <ciaranwoodward@xmos.com>
> Sent: 25 July 2022 17:23
> To: gdb-patches@sourceware.org
> Cc: Ciaran Woodward <ciaranwoodward@xmos.com>
> Subject: [PATCH] gdb: Fix missing first breakpoint in schedule-multiple
> mode
> 
> Rationale/background:
> When using schedule-multiple (sched_multi) in gdb, all inferiors
> are set to continue when the c command is used. However, before
> this patch, only the 'current' inferior would have its
> control->stop_soon field cleared. This field causes certain stops
> to be ignored, and is only intended for initial attach.
> 
> By not clearing this field before continue, continuing with inferior 2
> in focus and with inferior 1 hitting the next breakpoint, would cause
> gdb to ignore the breakpoint and any attempt to stop the target with
> Ctrl-C following that - even though the target was already stopped.
> The only fix was to quit GDB and restart.
> 
> Solution:
> With this patch, all inferiors being resumed have their
> control->stop_soon fields cleared, so gdb does not ignore the
> breakpoints of any inferior inadvertently.
> ---
>  gdb/infrun.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 543cccc5311..894157ed1d1 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -2808,18 +2808,18 @@ clear_proceed_status (int step)
>  	 we're about to resume, implicitly and explicitly.  */
>        for (thread_info *tp : all_non_exited_threads (resume_target,
> resume_ptid))
>  	clear_proceed_status_thread (tp);
> +
> +      for(struct inferior* inferior :
> all_non_exited_inferiors(resume_target))
> +        inferior->control.stop_soon = NO_STOP_QUIETLY;
>      }
> 
> -  if (inferior_ptid != null_ptid)
> +  if (non_stop && inferior_ptid != null_ptid)
>      {
>        struct inferior *inferior;
> 
> -      if (non_stop)
> -	{
> -	  /* If in non-stop mode, only delete the per-thread status of
> -	     the current thread.  */
> -	  clear_proceed_status_thread (inferior_thread ());
> -	}
> +      /* If in non-stop mode, only delete the per-thread status of
> +         the current thread.  */
> +      clear_proceed_status_thread (inferior_thread ());
> 
>        inferior = current_inferior ();
>        inferior->control.stop_soon = NO_STOP_QUIETLY;
> --
> 2.25.1

[PING 4][PATCH] gdb: Fix missing first breakpoint in schedule-multiple mode

[Ciaran Woodward]

Hi,

Ping 4 - this (or something similar) is required for working with multiple inferiors on a remote if you connect to the remote while the inferiors are already running. There is a reproduction description here: https://sourceware.org/pipermail/gdb-patches/2022-July/191092.html

Please let me know if there is anything else I should do to help move this along.

Cheers,
Ciaran

> -----Original Message-----
> From: Ciaran Woodward <ciaranwoodward@xmos.com>
> Sent: 25 July 2022 17:23
> To: gdb-patches@sourceware.org
> Cc: Ciaran Woodward <ciaranwoodward@xmos.com>
> Subject: [PATCH] gdb: Fix missing first breakpoint in schedule-multiple
> mode
> 
> Rationale/background:
> When using schedule-multiple (sched_multi) in gdb, all inferiors
> are set to continue when the c command is used. However, before
> this patch, only the 'current' inferior would have its
> control->stop_soon field cleared. This field causes certain stops
> to be ignored, and is only intended for initial attach.
> 
> By not clearing this field before continue, continuing with inferior 2
> in focus and with inferior 1 hitting the next breakpoint, would cause
> gdb to ignore the breakpoint and any attempt to stop the target with
> Ctrl-C following that - even though the target was already stopped.
> The only fix was to quit GDB and restart.
> 
> Solution:
> With this patch, all inferiors being resumed have their
> control->stop_soon fields cleared, so gdb does not ignore the
> breakpoints of any inferior inadvertently.
> ---
>  gdb/infrun.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 543cccc5311..894157ed1d1 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -2808,18 +2808,18 @@ clear_proceed_status (int step)
>  	 we're about to resume, implicitly and explicitly.  */
>        for (thread_info *tp : all_non_exited_threads (resume_target,
> resume_ptid))
>  	clear_proceed_status_thread (tp);
> +
> +      for(struct inferior* inferior :
> all_non_exited_inferiors(resume_target))
> +        inferior->control.stop_soon = NO_STOP_QUIETLY;
>      }
> 
> -  if (inferior_ptid != null_ptid)
> +  if (non_stop && inferior_ptid != null_ptid)
>      {
>        struct inferior *inferior;
> 
> -      if (non_stop)
> -	{
> -	  /* If in non-stop mode, only delete the per-thread status of
> -	     the current thread.  */
> -	  clear_proceed_status_thread (inferior_thread ());
> -	}
> +      /* If in non-stop mode, only delete the per-thread status of
> +         the current thread.  */
> +      clear_proceed_status_thread (inferior_thread ());
> 
>        inferior = current_inferior ();
>        inferior->control.stop_soon = NO_STOP_QUIETLY;
> --
> 2.25.1