27 August 2011, 13:19 | #1 |
Registered User
Join Date: Jul 2009
Location: Lala Land
Posts: 604
|
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?
|
29 August 2011, 10:14 | #2 | |
Registered User
Join Date: Aug 2006
Location: Italy
Posts: 109
|
Quote:
|
|
29 August 2011, 10:56 | #3 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Oops, forgot to reply. Yeah, I don't see the point in emulator remote debugging. Emulator debuggers are already sort of "remote"
|
29 August 2011, 16:18 | #4 |
Registered User
Join Date: Jan 2011
Location: Pittsburgh, PA
Posts: 31
|
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. |
30 August 2011, 11:31 | #5 | |
Registered User
Join Date: Jul 2009
Location: Lala Land
Posts: 604
|
Quote:
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. |
|
30 August 2011, 18:00 | #6 |
Registered User
Join Date: Jan 2011
Location: Pittsburgh, PA
Posts: 31
|
|
31 August 2011, 01:05 | #7 |
Registered User
Join Date: Jul 2009
Location: Lala Land
Posts: 604
|
This actually sounds better, after all I would want to disassemble programs not raw memory :-) Thanks for the heads up!
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Debugging my dodgy asm! | hypnoshock | Coders. Asm / Hardware | 5 | 01 May 2012 01:55 |
Debugging and JIT issues | copse | support.WinUAE | 4 | 01 April 2012 05:50 |
Serial debugging while booting | jman | Coders. General | 1 | 25 March 2012 03:02 |
Help debugging a faulty CD32 | UberFreak | support.Hardware | 0 | 23 October 2009 03:29 |
Enforcer debugging tool | M&F | support.WinUAE | 0 | 21 May 2002 22:53 |
|
|