While looking into PR31632, I did the following experiment. In the sources: ... $ cd gdb/testsuite $ mkdir backup $ mv gdb.*/backup $ mv backup/gdb.server backup/gdb.xml . ... In the build dir: ... $ make -j 16 \ check//unix/-m64 \ check//unix/-m64/-fPIE/-pie\ check//unix/-m32 \ check//unix/-m32/-fPIE/-pie ... I reproducibly run into a FAIL in gdb.server/server-kill-python: ... $ grep ^FAIL: build/gdb/testsuite.*/gdb.sum build/gdb/testsuite.unix.-m32.-fPIE.-pie/gdb.sum:FAIL: gdb.server/server-kill-python.exp: ensure inferior is running build/gdb/testsuite.unix.-m32/gdb.sum:FAIL: gdb.server/server-kill-python.exp: ensure inferior is running ... In more detail: ... spawn /data/vries/gdb/leap-15-5/build/gdb/testsuite.unix.-m32/../../gdb/gdbserver/gdbserver --once localhost:2346 /data/vries/gdb/leap-15-5/build/gdb/testsuite.unix.-m32/outputs/gdb.server/server-kill-python/server-kill-python^M Process /data/vries/gdb/leap-15-5/build/gdb/testsuite.unix.-m32/outputs/gdb.server/server-kill-python/server-kill-python created; pid = 3817^M Listening on port 2346^M spawn /data/vries/gdb/leap-15-5/build/gdb/testsuite.unix.-m32/../../gdb/gdb -nw -nx -data-directory /data/vries/gdb/leap-15-5/build/gdb/testsuite.unix.-m32/../data-directory -quiet -iex set height 0 -iex set width 0 -ex source /data/vries/gdb/leap-15-5/build/gdb/testsuite.unix.-m32/outputs/gdb.server/server-kill-python/file1.py^M Remote debugging from host ::1, port 38736^M FAIL: gdb.server/server-kill-python.exp: ensure inferior is running ... I.m able to reproduce this with plain target board unix/-m32 at the originating commit.
(In reply to Tom de Vries from comment #0) > > I.m able to reproduce this with plain target board unix/-m32 at the > originating commit. That's probably a red herring, after running from the command line I see behaviour consistent with the problem fixed by https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=037e8112b9794a633248e5aa5943f3be273e0a20 .
https://sourceware.org/pipermail/gdb-patches/2024-April/208057.html
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=75d277b1f506dcfbedfee3bef078dfe2b484958b commit 75d277b1f506dcfbedfee3bef078dfe2b484958b Author: Tom de Vries <tdevries@suse.de> Date: Wed Apr 17 11:45:02 2024 +0200 [gdb/testsuite] Fix gdbserver pid in gdb.server/server-kill-python.exp The commit ed32754a8c7 ("[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target") intended to addresss the problem that this command: ... set gdbserver_pid [exp_pid -i $server_spawn_id] ... does not return the pid of the gdbserver for remote target, but rather the one of the ssh client session. To fix this, it added another way of getting the gdbserver_pid. For the trivial case of non-remote target, the PID found by either method should be identical, but if we compare those by adding "puts [exec ps -p $gdbserver_pid]" we get: ... PID TTY TIME CMD 31711 pts/8 00:00:00 gdbserver PID TTY TIME CMD 31718 pts/8 00:00:00 server-kill-pyt ... The problem is that while the gdbserver PID is supposed to be read from the result of "gdb.execute ('p server_pid')" in the python script, instead it's taken from: ... Process server-kill-python created; pid = 31718^M ... Fix this by moving the printing of the gdbserver PID out of the python script. Also double-check the two methods against each other, in the cases that they should match. Tested on x86_64-linux. PR testsuite/31633 https://sourceware.org/bugzilla/show_bug.cgi?id=31633
Fixed.