[Bug testsuite/31632] [gdb/testsuite] Connecting to wrong gdbserver during parallel testing

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31632

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
I'm not sure exactly how this failure is caused, but I think making sure
test-cases run in parallel get unique portnums is a way to fix this.

The current approach is that we have:
...
global portnum
set portnum "2345"
...
and in gdbserver_start we do:
...
        # Bump the port number to avoid conflicts with hung ports.              
        incr portnum
...
which works ok for serial testing.

There there's this bit:
...
           -re "Can't (bind address|listen on socket): Address already in
use\\.\r\n" {
                verbose -log "Port $portnum is already in use."
                if ![target_info exists gdb,socketport] {
                    # Bump the port number to avoid the conflict.               
                    wait -i $expect_out(spawn_id)
                    incr portnum
                    continue
                }
            }
...
which should avoid clashes with other uses.

We can't avoid clashes completely, given that things may happen outside of the
scope of gdb testing, but we should avoid running into clashes due to parallel
gdb testing.

So, we're gonna need a unique dir that needs to be created/emptied when making
make-target check//%, and passed down using a variable say, GDB_LOCK_DIR.

Each make invocation can then check GDB_LOCK_DIR, if it doesn't exist (because
of not using make check//), create it's own and use it, and if it does, use
that one.

[ I then wonder what happens when using check// and plain check next to each
other.  But perhaps this is already unsupported/broken today. ]

Then we can track portnum in $GDB_LOCK_DIR/portnum and use
$GDB_LOCK_DIR/portnum.lock to serialize parallel access.

-- 
You are receiving this mail because:
You are on the CC list for the bug.