Remote GDB debugging

[copse]

The debugging support in WinUAE looks more than capable, but one feature I like in other emulators that has been very helpful is support for remote GDB debugging. This would provide the wealth of full GDB debugging support with a standardised GUI (Insight). You ever considered supporting it Toni?

[ceztko]

Originally Posted by copse

The debugging support in WinUAE looks more than capable, but one feature I like in other emulators that has been very helpful is support for remote GDB debugging. This would provide the wealth of full GDB debugging support with a standardised GUI (Insight). You ever considered supporting it Toni?

Debugging of the emulator itself or of the emulated cpu instructions? First case: not possible because WinUAE can compile on VS only and anyway would make sense only for beta testing of a debug build of WinUAE. Second case: even if WinUAE would be able to offer a GDB compatible debugging host, why remote debugging (TCP/IP or serial) would be useful for you?

[Toni Wilen]

Oops, forgot to reply. Yeah, I don't see the point in emulator remote debugging. Emulator debuggers are already sort of "remote"

[Ezrec]

Actually, you can use C:GDBStub and C:GDBStop from the aros-m68k-system.iso from the aros.org download section. Make sure to get the ISO - it's in AOS HUNK format. The tarball is for debugging AROS itself, and is in ELF format.

It runs on not only AROS, but also KS 1.3 ... KS 3.x, and uses the serial port for the debug port.

C:GDBStub is a self-detaching program, and installs hooks into Exec/Alert(), the TRAP vectors, and every newly run program's default tc_TrapHook. When those hooks trigger, it starts up a GDB Stub target on the serial port.

(You can use C:GDBStop to start a GDB Stub session manually)

I don't use WinUAE myself (I'm on Linux), but I think Toni might have a TCP serial port option in the latest Beta series.

You can then use a m68k-elf-gdb on your host with the 'target remote localhost:1234' command to make a local connection to the emulator's serial port.

NOTE: When using C:GDBStop, you'll need to 'set $pc=$pc+2' to skip over the 'trap #1' instruction before continuing execution.

[copse]

Originally Posted by ceztko

Debugging of the emulator itself or of the emulated cpu instructions? First case: not possible because WinUAE can compile on VS only and anyway would make sense only for beta testing of a debug build of WinUAE. Second case: even if WinUAE would be able to offer a GDB compatible debugging host, why remote debugging (TCP/IP or serial) would be useful for you?

Emulated CPU instructions.

It decouples the debugging tool from the emulator for the most part. This means that people can use an external debugger with more advanced functionality or a standard interface. Eclipse CDT and IDA are both tools that support remote GDB debugging (although not sure the latter supports m68k remote debugging). It means that the debugger can be customised (in the case of Eclipse) without needing to touch the emulator. Etc.

Now, I am not pushing for it. It is on my list of interesting projects I would like to do should I find the time and interest. Just wanted to see if it had been thought about.

[Ezrec]

Originally Posted by Ezrec

It runs on not only AROS, but also KS 1.3 ... KS 3.x

Oops! My bad! KS 3.x and later only (for now). KS 1.3 support is.. eh.. lacking.

[copse]

Originally Posted by Ezrec

C:GDBStub is a self-detaching program, and installs hooks into Exec/Alert(), the TRAP vectors, and every newly run program's default tc_TrapHook. When those hooks trigger, it starts up a GDB Stub target on the serial port.

This actually sounds better, after all I would want to disassemble programs not raw memory :-) Thanks for the heads up!