10

Does any emulator have an interface, let's say with sockets, to which an arbitrary application can connect and get data so as to implement a debugger or monitor, etc?

I know you could achieve this by scripting, some emus support this, but I specifically look for some kind of standard I can adhere to for my own emulator as well.

Improve this question
2
  • 2
    What are you trying to debug? The emulator or the OS running under emulation?
    – another-dave
    Aug 12, 2021 at 22:56
  • 1
    It's a C64 emulator and I'm using VICE ROMs, so I trust they work fine. I'm trying to monitor what's happening in the emulated machine to check if my emulator is working fine. Also I'll be implementing IO and other registers as I go, implementing only the ones that are actually used by the programs I test and by the boot up sequence with the kernal.
    – Petruza
    Aug 13, 2021 at 16:14

2 Answers 2

Reset to default
14

The popular VICE emulator for Commodore computers supports connecting to its in-built monitor using TCP port 6510. You can test this easily by loading the emulator, then Settings → Machine → Monitor → "Enable remote monitor". Once this is done, the familiar monitor interface is accessible using telnet localhost 6510.

While not representative of a "broad standard", the machine-language monitor commands and output supported by VICE are a practical "de-facto standard" for debugging Commodore machines. So, this is most practical if you were looking to add debugging to some 6502 CPU family of emulators, or just create a better UI for debugging Commodore software running in VICE.

Improve this answer
2
  • I'm coding a C64 emu, so this is quite interesting, thanks!
    – Petruza
    Aug 13, 2021 at 16:16
  • 2
    Connect to port 6510 to debug the MOS 6510 inside the C64? Nice.
    – ssokolow
    Aug 13, 2021 at 19:53
29

If you're looking for a standard to adhere to, I'd consider implementing the GDB remote protocol. (Link is to Embecosm's guide on writing a GDB Remote Serial Protocol server.)

It needs GDB to support the ISA you're targeting (I've heard it's the same sort of "build a special cross-targeting version" song and dance as with GCC), but, people have gotten GDB to support a lot of architectures (eg. STM8, despite GCC not supporting it) and, in the worst case, you could always implement both sides of the conversation yourself and have a non-GDB debugger that's very friendly to someone coming along later and adding support to GDB because it speaks a standard language.

Here are some things which implement it:

  • gdbserver is GDB's own tool for letting a GDB instance on one machine that can run GDB debug a program running on another machine that can run GDB. (eg. So you can debug something on a co-located server using your local copy of GDB. It's also what Android uses.)
  • Wine's WineDbg has a GDB mode.
  • The KDB/KGDB debugger supports GDB remoting over serial. (According to Wikipedia, it's available for Linux, FreeBSD, and NetBSD kernels.)
  • QEMU (x86, x86-64 PCs, MIPS64, SPARC, ARM, SH4, PPC, RISC-V, etc.) has an implementation. (Here's Xilinx's guide for using it to debug ARM stuff and here's a post on how to use it to debug real-mode x86, because the QEMU wiki page I linked is such a stub.)
  • The Bochs x86 emulator can be built with GDB support.
  • VMWare Workstation (but not VMWare Player) implements GDB support.
  • Someone's written a v0.1 pre-release of GDB support for VirtualBox.
  • Apple's debugserver for iOS implements gdb protocol as does Google Project Zero's ktrr for kernel-debugging jailbroken iPhones.
  • OpenOCD provides a server to translate between GDB remote protocol and the on-chip debugging functionality of programmers like the ST-Link. (The programmer you can get a $2 Chinese clone of to program your $1 Chinese STM8 and $2 Chinese STM32 dev boards.)
  • Various official devkits include GDB remote support, such as the official STMicro ST-LINK server that OpenOCD serves as a less proprietary alternative to.
  • The BlackMagic probe is firmware you can flash to an ST-Link or buy flashed into purpose-built hardware which implements programming and the GDB protocol directly on the device for various ARM Cortex-M and Cortext-A devices such as various STM32 sub-series.
  • According to the Qt Creator Connecting Bare Metal Devices page, EBLink and J-Link also implement GDB protocol support.
  • Though they don't mention it on their site as far as I can tell, mGBA has a GDB implementation that can be enabled from the GUI.
  • According to this 2020 StackOverflow answer, VisualBoyAdvance-M has GDB support, but this post said that "VBA gdb connection hasn't worked in a very long time" in 2018, so I'm assuming that VBA-M un-broke GDB support added by the original project.
  • There are patches for certain revisions of DOSBox.

(It's sort of amazing that some things running compatible ISAs don't implement GDB support natively. VirtualBox's built-in debugger is described as being like the OS/2 and CodeView debuggers.)

Here are some GDB frontends which explicitly list support for remote debugging:

IDA Pro also implements support for debugging things that speak GDB's protocol if that's your preference but x64dbg does not [1] [2].

Improve this answer
3
  • For frontends, CLion works too, it even has support for ARM's .svd files for peripheral register viewing. Second, there are multiple GDB stub implementations which allow debugging over a serial protocol without using a hardware debugger.
    – jaskij
    Aug 13, 2021 at 13:02
  • Many distributions now have gdb-multiarch package so cross compiling is not necessary. The command set architecture inside gdb will list supported archs.
    – jpa
    Aug 14, 2021 at 16:39
  • 1
    @jpa Assuming it's something in mainline upstream like m68k or ARM. Otherwise, you're still going to need to install something like gdb-avr or that STM8 version I linked to... but thanks. I wasn't aware of gdb-multiarch.
    – ssokolow
    Aug 15, 2021 at 0:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .