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

[Ciaran Woodward <ciaranwoodward@xmos.com>]

> 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