English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   support.WinUAE (https://eab.abime.net/forumdisplay.php?f=5)
-   -   Remote GDB debugging (https://eab.abime.net/showthread.php?t=60759)

copse 27 August 2011 13:19

Remote GDB debugging
 
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 29 August 2011 10:14

Quote:

Originally Posted by copse (Post 774469)
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 29 August 2011 10:56

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

Ezrec 29 August 2011 16:18

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 30 August 2011 11:31

Quote:

Originally Posted by ceztko (Post 774770)
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 30 August 2011 18:00

Quote:

Originally Posted by Ezrec (Post 774818)
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 31 August 2011 01:05

Quote:

Originally Posted by Ezrec (Post 774818)
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!


All times are GMT +2. The time now is 09:30.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.22584 seconds with 11 queries