Re: test gdb as it runs qemu simulator

Hi George,

On 29/10/2025 20:21, Mock, George via Gdb wrote:
> Hello!
> 
> I work on a team that implements C/C++ cross compilers.  Among other combinations, one cross compiler runs on Linux and generates code for RISC-V systems.  I want to use the gdb testsuite.  Not for the purpose of testing gdb, but to test whether the Dwarf generated by our compiler works with gdb.  I need to test gdb while it controls execution of code running under a qemu simulator for RISC-V.
> 
> The following shows a typical way, from Linux, to interactively use gdb on one program.
> 
> # In one process
> $ qemu-riscv32 -g 1234 riscv-program
> 
> # In a different process
> $ riscv32-unknown-elf-gdb riscv-program
> (gdb) target remote localhost:1234
> (gdb) # typical gdb commands go here
> 
> The option -g 1234 tells qemu-riscv32 to start gdbserver and wait for communication through port 1234.
> 
> I have some familiarity with testing gdb.  I learned how to build and test it for Linux.  I built riscv32-unknown-elf-gdb, and I can interactively watch it work.  I know how to configure the testsuite to build with our cross compiler.  But I cannot find the configuration (I presume some combination of a board file and command line options) which causes the testsuite to interface with qemu-riscv32 in a manner similar to that interactive example.
> 
> While I would appreciate a fully fleshed out solution, I'm sure that is too much to expect.  I suspect many have done this before me, but none of my many searches have found the blog post (or whatever) which shows how they did it.

You're right that this has been done before, but the extra 
code/framework required unfortunately never made its way upstream. It 
might still exist in some company's internal repo.

The most important part is probably a dejagnu/TCL board file for user 
qemu (a qemu that acts as a gdbserver-like debugging stub). The 
complexity there is you'll need to implement/override the required TCL 
functions that can handle firing up QEMU, connecting to it, shutting it 
down for each testcase (or maybe just keeping a stable qemu running, but 
with a reset after each testcase) and the related quirks.

If you're looking at implementing and contributing it (which would be 
very much appreciated) a good starting point is the gdbserver files in 
gdb/testsuite/config/gdbserver.exp, 
gdb/testsuite/boards/gdbserver-base.exp, 
gdb/testsuite/boards/native-gdbserver.exp and 
gdb/testsuite/lib/gdbserver-support.exp (you may be able to reuse some 
of the functions here).

> 
> I'd appreciate any light you can shed.
> 
> Thanks and regards,
> 
> -George Mock
>