* test gdb as it runs qemu simulator
@ 2025-10-29 20:21 Mock, George via Gdb
2025-10-29 22:05 ` Luis via Gdb
2025-10-31 20:33 ` Tom Tromey
0 siblings, 2 replies; 4+ messages in thread
From: Mock, George via Gdb @ 2025-10-29 20:21 UTC (permalink / raw)
To: gdb
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.
I'd appreciate any light you can shed.
Thanks and regards,
-George Mock
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: test gdb as it runs qemu simulator
2025-10-29 20:21 test gdb as it runs qemu simulator Mock, George via Gdb
@ 2025-10-29 22:05 ` Luis via Gdb
2025-10-31 20:32 ` Tom Tromey
2025-10-31 20:33 ` Tom Tromey
1 sibling, 1 reply; 4+ messages in thread
From: Luis via Gdb @ 2025-10-29 22:05 UTC (permalink / raw)
To: Mock, George, gdb
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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: test gdb as it runs qemu simulator
2025-10-29 22:05 ` Luis via Gdb
@ 2025-10-31 20:32 ` Tom Tromey
0 siblings, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2025-10-31 20:32 UTC (permalink / raw)
To: Luis via Gdb; +Cc: Mock, George, Luis
>> 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.
Luis> You're right that this has been done before, but the extra
Luis> code/framework required unfortunately never made its way upstream. It
Luis> might still exist in some company's internal repo.
I remembered seeing this before and found this:
https://inbox.sourceware.org/gdb-patches/20231204024634.419445-3-zeck654321@gmail.com/
I filed a bug to track the idea
https://sourceware.org/bugzilla/show_bug.cgi?id=33590
I don't know why that patch didn't land but I think it would be a good
addition. Perhaps a bit of cleanup would be needed.
Tom
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: test gdb as it runs qemu simulator
2025-10-29 20:21 test gdb as it runs qemu simulator Mock, George via Gdb
2025-10-29 22:05 ` Luis via Gdb
@ 2025-10-31 20:33 ` Tom Tromey
1 sibling, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2025-10-31 20:33 UTC (permalink / raw)
To: Mock, George via Gdb; +Cc: Mock, George
>>>>> Mock, George via Gdb <gdb@sourceware.org> writes:
> 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.
FWIW it's not unusual to discover that valid DWARF can trigger a gdb
bug. Feel free to file bugs for that kind of thing. Or send patches.
thanks,
Tom
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-10-31 20:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-29 20:21 test gdb as it runs qemu simulator Mock, George via Gdb
2025-10-29 22:05 ` Luis via Gdb
2025-10-31 20:32 ` Tom Tromey
2025-10-31 20:33 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox