tests/tcg: how should we skip a gdb test if the host's gdb isn't new enough?

tests/tcg: how should we skip a gdb test if the host's gdb isn't new enough?

[Peter Maydell]

I noticed that the gdbstub/memory.py test hangs for me when it tries
to test the loongarch64 architecture. Running it as a standalone
test (which is what "make check" does) hangs too (transcript at
end of mail).

I'm guessing that the fundamental cause of this is that my host
gdb doesn't like talking to the gdbstub, and reports in the log:
"warning: Architecture rejected target-supplied description".
(The hang seems to be because we continually re-execute a
store insn that provokes a debug exception -- presumably the
gdb is not doing what it should at its end and reporting
and then deleting the watchpoint before continuing, so we just
keep reporting the watchpoint hit to gdb endlessly.)

The gdb is the gdb-multiarch Ubuntu one; --version reports
"GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1"

How in the gdbstub test framework should we detect "this gdb
isn't good enough for this architecture/test" and skip tests?


===begin===
$ /home/pm215/qemu/tests/tcg/../guest-debug/run-test.py --gdb
/usr/bin/gdb-multiarch --qemu
/home/pm215/qemu/build/loongarch-dbg/qemu-system-loongarch64 --qargs
'-display none -serial stdio -kernel' --bin
build/loongarch-dbg/tests/tcg/loongarch64-softmmu-memory.test --test
/home/pm215/qemu/build/loongarch-dbg/../../tests/tcg/multiarch/system/../gdbstub/memory.py
QEMU CMD: /home/pm215/qemu/build/loongarch-dbg/qemu-system-loongarch64
-display none -serial stdio -kernel
build/loongarch-dbg/tests/tcg/loongarch64-softmmu-memory.test -S -gdb
unix:path=/tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket,server=on
qemu-system-loongarch64: -gdb
unix:path=/tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket,server=on: info:
QEMU waiting for connection on:
disconnected:unix:/tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket,server=on
GDB CMD: /usr/bin/gdb-multiarch
build/loongarch-dbg/tests/tcg/loongarch64-softmmu-memory.test -q -n
-batch -ex 'set pagination off' -ex 'set confirm off' -ex 'target
remote /tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket' -x
/home/pm215/qemu/build/loongarch-dbg/../../tests/tcg/multiarch/system/../gdbstub/memory.py
warning: Architecture rejected target-supplied description
0x000000001c000000 in ?? ()
ATTACHED: Loongarch64
Checking we can step the first few instructions
0x000000001c000004 in ?? ()
0x000000001c000008 in ?? ()
0x000000001c00000c in ?? ()
PASS: single step in boot code
Setup catch-all for _exit
Breakpoint 1 at 0x220000: file
../../tests/tcg/loongarch64/system/boot.S, line 24.
Breakpoint 2 at 0x2015ec: file
/home/pm215/qemu/tests/tcg/multiarch/system/memory.c, line 510.

Breakpoint 2, main () at
/home/pm215/qemu/tests/tcg/multiarch/system/memory.c:510
510         bool ok = true;
PASS: break @ 0x2015ec <main+16> ({int (void)} 0x2015dc <main> 1 hits)
Hardware access (read/write) watchpoint 3: test_data[128]
Test data start: 0x238000
Test data end: 0x23c000
Filling test area with u8 (238000):.
Hardware access (read/write) watchpoint 3: test_data[128]

Value = 0 '\000'
init_test_data_u8 (unused_offset=0) at
/home/pm215/qemu/tests/tcg/multiarch/system/memory.c:77
77              *ptr++ = BYTE_NEXT(count);
PASS: awatch for test_data[128]
Hardware read watchpoint 4: test_data[128]
...............................................................................................................................done
16384 @ 23c000
Reading u16 from 0x238000 (offset 0):.
Hardware read watchpoint 4: test_data[128]

Value = 128 '\200'
read_test_data_u16 (offset=0) at
/home/pm215/qemu/tests/tcg/multiarch/system/memory.c:213
213             word = *ptr++;
PASS: rwatch for test_data[128]
Hardware watchpoint 5: test_data[128]
...............................................................done
8192 @ 23c000
Reading u32 from 0x238000 (offset
0):................................done 4096 @ 23c000
Reading u64 from 0x238000 (offset 0):................done 2048 @ 23c000
Filling test area with u16 (offset 0, 238000):.
===endit===

thanks
-- PMM

Re: tests/tcg: how should we skip a gdb test if the host's gdb isn't new enough?

[Pierrick Bouvier]

On 10/22/2026 8:51 AM, Peter Maydell wrote:
> I noticed that the gdbstub/memory.py test hangs for me when it tries
> to test the loongarch64 architecture. Running it as a standalone
> test (which is what "make check" does) hangs too (transcript at
> end of mail).
> 
> I'm guessing that the fundamental cause of this is that my host
> gdb doesn't like talking to the gdbstub, and reports in the log:
> "warning: Architecture rejected target-supplied description".
> (The hang seems to be because we continually re-execute a
> store insn that provokes a debug exception -- presumably the
> gdb is not doing what it should at its end and reporting
> and then deleting the watchpoint before continuing, so we just
> keep reporting the watchpoint hit to gdb endlessly.)
> 
> The gdb is the gdb-multiarch Ubuntu one; --version reports
> "GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1"
> 
> How in the gdbstub test framework should we detect "this gdb
> isn't good enough for this architecture/test" and skip tests?
>
Thanks for the report Peter.

There is no "minimum gdb version" set globally, but it can be set per
test defining a gdb feature.

I wrote a series (that fix current issue) here:
https://lore.kernel.org/qemu-devel/20261022201733.1941651-1-pierrick.bouvier@oss.qualcomm.com/T/#

Regards,
Pierrick

Re: tests/tcg: how should we skip a gdb test if the host's gdb isn't new enough?

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> I noticed that the gdbstub/memory.py test hangs for me when it tries
> to test the loongarch64 architecture. Running it as a standalone
> test (which is what "make check" does) hangs too (transcript at
> end of mail).
>
> I'm guessing that the fundamental cause of this is that my host
> gdb doesn't like talking to the gdbstub, and reports in the log:
> "warning: Architecture rejected target-supplied description".
> (The hang seems to be because we continually re-execute a
> store insn that provokes a debug exception -- presumably the
> gdb is not doing what it should at its end and reporting
> and then deleting the watchpoint before continuing, so we just
> keep reporting the watchpoint hit to gdb endlessly.)
>
> The gdb is the gdb-multiarch Ubuntu one; --version reports
> "GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1"

We used to check for 9.1 but all checking is done in meson since
00eb02b4f5f5 (configure: directly pass gdb path as a meson option). I
think you want to look for stanzas like:

  gdb_feat_version = {
    'sme-tiles': '14.1',
    'mte': '15.1',
    'mte-baremetal': '16.0',
  }


>
> How in the gdbstub test framework should we detect "this gdb
> isn't good enough for this architecture/test" and skip tests?
>

We could also do some architecture feature checking in
scripts/probe-gdb-support.py but version introspection is aboutthe best
we have these days.

>
> ===begin===
> $ /home/pm215/qemu/tests/tcg/../guest-debug/run-test.py --gdb
> /usr/bin/gdb-multiarch --qemu
> /home/pm215/qemu/build/loongarch-dbg/qemu-system-loongarch64 --qargs
> '-display none -serial stdio -kernel' --bin
> build/loongarch-dbg/tests/tcg/loongarch64-softmmu-memory.test --test
> /home/pm215/qemu/build/loongarch-dbg/../../tests/tcg/multiarch/system/../gdbstub/memory.py
> QEMU CMD: /home/pm215/qemu/build/loongarch-dbg/qemu-system-loongarch64
> -display none -serial stdio -kernel
> build/loongarch-dbg/tests/tcg/loongarch64-softmmu-memory.test -S -gdb
> unix:path=/tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket,server=on
> qemu-system-loongarch64: -gdb
> unix:path=/tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket,server=on: info:
> QEMU waiting for connection on:
> disconnected:unix:/tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket,server=on
> GDB CMD: /usr/bin/gdb-multiarch
> build/loongarch-dbg/tests/tcg/loongarch64-softmmu-memory.test -q -n
> -batch -ex 'set pagination off' -ex 'set confirm off' -ex 'target
> remote /tmp/tmpodrh2895qemu-gdbstub/gdbstub.socket' -x
> /home/pm215/qemu/build/loongarch-dbg/../../tests/tcg/multiarch/system/../gdbstub/memory.py
> warning: Architecture rejected target-supplied description
> 0x000000001c000000 in ?? ()
> ATTACHED: Loongarch64
> Checking we can step the first few instructions
> 0x000000001c000004 in ?? ()
> 0x000000001c000008 in ?? ()
> 0x000000001c00000c in ?? ()
> PASS: single step in boot code
> Setup catch-all for _exit
> Breakpoint 1 at 0x220000: file
> ../../tests/tcg/loongarch64/system/boot.S, line 24.
> Breakpoint 2 at 0x2015ec: file
> /home/pm215/qemu/tests/tcg/multiarch/system/memory.c, line 510.
>
> Breakpoint 2, main () at
> /home/pm215/qemu/tests/tcg/multiarch/system/memory.c:510
> 510         bool ok = true;
> PASS: break @ 0x2015ec <main+16> ({int (void)} 0x2015dc <main> 1 hits)
> Hardware access (read/write) watchpoint 3: test_data[128]
> Test data start: 0x238000
> Test data end: 0x23c000
> Filling test area with u8 (238000):.
> Hardware access (read/write) watchpoint 3: test_data[128]
>
> Value = 0 '\000'
> init_test_data_u8 (unused_offset=0) at
> /home/pm215/qemu/tests/tcg/multiarch/system/memory.c:77
> 77              *ptr++ = BYTE_NEXT(count);
> PASS: awatch for test_data[128]
> Hardware read watchpoint 4: test_data[128]
> ...............................................................................................................................done
> 16384 @ 23c000
> Reading u16 from 0x238000 (offset 0):.
> Hardware read watchpoint 4: test_data[128]
>
> Value = 128 '\200'
> read_test_data_u16 (offset=0) at
> /home/pm215/qemu/tests/tcg/multiarch/system/memory.c:213
> 213             word = *ptr++;
> PASS: rwatch for test_data[128]
> Hardware watchpoint 5: test_data[128]
> ...............................................................done
> 8192 @ 23c000
> Reading u32 from 0x238000 (offset
> 0):................................done 4096 @ 23c000
> Reading u64 from 0x238000 (offset 0):................done 2048 @ 23c000
> Filling test area with u16 (offset 0, 238000):.
> ===endit===
>
> thanks
> -- PMM

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro