gdb: make "start" breakpoint inferior-specific

I saw this failure on a CI:

    (gdb) add-inferior
    [New inferior 2]
    Added inferior 2
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: add-inferior
    inferior 2
    [Switching to inferior 2 [<null>] (<noexec>)]
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 2
    kill
    The program is not being run.
    (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
    Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep...
    (gdb) run &
    Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: run inferior 2
    inferior 1
    [Switching to inferior 1 [<null>] (<noexec>)]
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 1
    kill
    The program is not being run.
    (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
    Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior...
    (gdb) break should_break_here
    Breakpoint 1 at 0x11b1: file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.c, line 25.
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: break should_break_here
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    start
    Temporary breakpoint 2 at 0x11c0: -qualified main. (2 locations)
    Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

    Thread 2.1 "vfork-multi-inf" hit Temporary breakpoint 2, main () at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior-sleep.c:23
    23	  sleep (30);
    (gdb) FAIL: gdb.threads/vfork-multi-inferior.exp: method=non-stop: start inferior 1

What happens is:

 1. We start inferior 2 with "run&", it runs very slowly, takes time to
    get to main
 2. We switch to inferior 1, and run "start"
 3. The temporary breakpoint inserted by "start" applies to all inferiors
 4. Inferior 2 hits that breakpoint and GDB reports that hit

To avoid this, breakpoints inserted by "start" should be
inferior-specific.  However, we don't have a nice way to make
inferior-specific breakpoints yet.  It's possible to make
pspace-specific breakpoints (for example how the internal_breakpoint
constructor does) by creating a symtab_and_line manually.  However,
inferiors can share program spaces (usually on particular embedded
targets), so we could have a situation where two inferiors run the same
code in the same program space.  In that case, it would just not be
possible to insert a breakpoint in one inferior but not the other.

A simple solution that should work all the time is to add a condition to
the breakpoint inserted by "start", to check the inferior reporting the
hit is the expected one.  This is what this patch implements.

Add a test that does:

 - start in background inferior 1 that sleeps before reaching its main
   function (using a sleep in a global C++ object's constructor)
 - start inferior 2 with the "start" command, which also sleeps before
   reaching its main function
 - validate that we hit the breakpoint in inferior 2

Without the fix, we hit the breakpoint in inferior 1 pretty much all the
time.  There could be some unfortunate scheduling causing the test not
to catch the bug, for instance if the scheduler decides not to schedule
inferior 1 for a long time, but it would be really rare.  If the bug is
re-introduced, the test will catch it much more often than not, so it
will be noticed.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: Ib0148498a476bfa634ed62353c95f163623c686a

0 files changed, 0 insertions, 0 deletions