Built-in debugger server

[XVilka]

Many emulators support ways to debug their guests using more suitable tools - GDB, LLDB, EDB, WinDbg, IDA Pro, etc.

Implementing something like gdbstub, just like QEMU does this, will allow remote debugger connection, e.g. GDB itself, or something else:

qemu on  master [?]                                                                                                                                                                                        16:56:06
ℤ rg gdbstub -l
target/nios2/nios2-semi.c
target/sparc/gdbstub.c
target/rx/gdbstub.c
target/rx/meson.build
target/sparc/meson.build
target/nios2/cpu.c
target/alpha/gdbstub.c
target/arm/gdbstub.c
target/arm/gdbstub64.c
target/riscv/gdbstub.c
target/arm/hyp_gdbstub.c
target/arm/ptw.c
target/arm/meson.build
target/arm/kvm64.c
target/arm/hvf/hvf.c
target/arm/tcg/helper-a64.c
target/arm/tcg/translate.h
target/arm/tcg/m_helper.c
target/riscv/meson.build
target/alpha/meson.build
target/microblaze/gdbstub.c
target/tricore/gdbstub.c
target/mips/gdbstub.c
target/mips/meson.build
target/tricore/meson.build
target/mips/tcg/sysemu/mips-semi.c
target/mips/tcg/sysemu/cp0_helper.c
target/microblaze/meson.build
target/microblaze/cpu.c
target/loongarch/gdbstub.c
target/cris/gdbstub.c
target/cris/meson.build
target/loongarch/meson.build
target/hexagon/gdbstub.c
target/openrisc/mmu.c
target/openrisc/gdbstub.c
target/ppc/gdbstub.c
target/ppc/meson.build
target/ppc/cpu_init.c
target/ppc/internal.h
target/ppc/kvm.c
target/openrisc/meson.build
target/openrisc/interrupt.c
target/hexagon/meson.build
target/hexagon/cpu.c
target/i386/meson.build
target/hppa/gdbstub.c
target/xtensa/core-dsp3400.c
target/i386/tcg/translate.c
target/avr/gdbstub.c
target/s390x/gdbstub.c
target/avr/meson.build
target/s390x/s390x-internal.h
target/s390x/meson.build
target/s390x/helper.c
target/s390x/kvm/kvm.c
target/xtensa/gdbstub.c
target/xtensa/core-de233_fpu.c
target/xtensa/core-fsf.c
target/xtensa/core-dc232b.c
target/xtensa/core-test_mmuhifi_c3.c
target/xtensa/core-test_kc705_be.c
target/xtensa/helper.c
target/xtensa/meson.build
target/xtensa/core-sample_controller.c
target/xtensa/core-de212.c
target/xtensa/core-lx106.c
target/xtensa/import_core.sh
target/xtensa/core-dc233c.c
target/i386/gdbstub.c
target/hppa/meson.build
target/i386/kvm/kvm.c
target/m68k/meson.build
target/m68k/helper.c
target/sh4/gdbstub.c
target/m68k/gdbstub.c
target/m68k/m68k-semi.c
target/sh4/meson.build
target/i386/whpx/whpx-all.c
gdbstub/meson.build
gdbstub/gdbstub.c
gdbstub/trace.h
gdbstub/trace-events
gdbstub/syscalls.c
gdbstub/internals.h
gdbstub/user.c
gdbstub/softmmu.c
gdbstub/user-target.c
semihosting/guestfd.c
semihosting/console.c
semihosting/arm-compat-semi.c
semihosting/syscalls.c
linux-user/signal.c
linux-user/main.c
scripts/probe-gdb-support.py
linux-user/exit.c
scripts/feature_to_c.sh
softmmu/cpus.c
softmmu/vl.c
softmmu/runstate.c
accel/kvm/kvm-all.c
accel/accel-common.c
accel/hvf/hvf-accel-ops.c
accel/tcg/tcg-all.c
accel/tcg/tcg-accel-ops.c
meson.build
MAINTAINERS
docs/system/introduction.rst
docs/system/gdb.rst
docs/about/emulation.rst
tests/guest-debug/test-gdbstub.py
tests/guest-debug/run-test.py
tests/tcg/aarch64/gdbstub/test-sve.py
tests/tcg/aarch64/Makefile.target
tests/tcg/aarch64/sve-ioctls.c
tests/tcg/multiarch/gdbstub/test-proc-mappings.py
tests/tcg/multiarch/gdbstub/test-thread-breakpoint.py
tests/tcg/multiarch/gdbstub/memory.py
tests/tcg/multiarch/gdbstub/test-qxfer-auxv-read.py
tests/tcg/multiarch/Makefile.target
tests/tcg/multiarch/system/Makefile.softmmu-target
tests/tcg/arm/test-armv6m-undef.S
tests/tcg/s390x/Makefile.target
tests/avocado/reverse_debugging.py
include/gdbstub/helpers.h
include/gdbstub/user.h
include/qemu/accel.h
include/sysemu/accel-ops.h
include/exec/replay-core.h
include/exec/translation-block.h
include/exec/gdbstub.h
configure
monitor/hmp-cmds.c
stubs/gdbstub.c
stubs/meson.build
bsd-user/qemu.h
bsd-user/signal.c
bsd-user/main.c
bsd-user/freebsd/os-syscall.c

[markpizz]

It sounds like what you want is a way to debug things running with a simulator and not the simulator itself which can already be debugged directly with normal software tools.

If that is true, then gdbstub could be used to interface and control the contents of simulators using possibly some simulator specific code and the simh frontpanel API.

If you want to explore this and you actually have a use case for one or more simulators, I'll be glad to work with your to put something together.

Someone's long ago request for something like this was one of the inspirations for implementing the frontpanel API.

Feel free to contact me here or offline at mark@infocomm.com

[pkoning2]

A number of simulators already have a breakpoint facility. So with that and basic things like register and memory access you have pretty much all the things needed for GDB. The stub protocol is quite easy. The obvious issue is that GDB supports few of the ISAs that SIMH emulates. VAX is about the only one that comes to mind. I've toyed with doing a quick & dirty PDP11 GDB, but that's made problematic by the fact that GDB is dropping support for STABS (which wasn't reliable anyway) and there isn't a PDP11 ELF handler. Or rather there is most of one but the author died last year and so far I haven't been able to get permission to publish it. I suppose it could be redone, it should not be terribly hard.

[bscottm]

@XVilka: Can you write up an initial design? Are you leveraging the gdbstub protocol with existing SIMH internals? Or a whole new debugger?

[XVilka]

Yes. Leveraging GDBRemote protocol looks like easiest and proven solution, even if the GDB itself might not support the target architecture. As for STABS we plan to implement it in Rizin: https://github.com/rizinorg/rizin/issues/3578 Rizin doesn't support all architectures but already can handle GDB protocol out of the box. I am thinking if it makes possible to leverage that.

[bscottm]

I can see how the Rizin effort might be useful, e.g., reverse engineering VAX diagnostics or PDP-11 diagnostics. There's a little more to this design that needs expansion, though.

@pkoning2, @sethm: @XVilka's proposal adds the GDB remote debugging protocol as a frontend to SIMH. That would make it possible for the Rizin tools to reverse engineer VAX diagnostics (or the 3b2 diags) and potentially recover them as C code or as documented assembler sources.

@XVilka: STABS is a debugging format; I'm not conceptually connecting STABS to the GDB remote protocol. Would it be used to augment the reverse engineering process by tracking symbolic info associated with the image being reverse engineered? Where would that STABS info get stored?

Also, adding an alternate frontend to SIMH suggests fixing the SDL weirdness. SDL should always be the main thread (implying that the SIMH command line lives in its own thread), per the SDL design, not just for macOS and BESM6. That would result in a more consistent compile methodology, vice exceptions for platforms and specific simulators.

[pkoning2]

The reason I mentioned STABS is that the debugger wants a binary format that includes debug data, and the compiler and/or assembler needs to generate that. STABS is the old format which is rapidly disappearing, ELF with DWARF is the new one. The issue is that some GCC targets -- pdp11 at least -- is only STABS and that was actually removed from GCC recently, so the current GCC still supports pdp11 but without debug data. pdp11-elf is doable but not done yet. For VAX it is, I believe. The other question is what to do about older ISAs for which no debug format was ever defined -- for example, remote debugging of IBM 1620 is presumably doable, but it wouldn't be symbolic.