08 January 2018, 02:38 | #1 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
Debugging strategies
After spending some time converting ADoom 1.4 to beppo's GCC 6.2 toolchain, I'm sort of hitting a wall.
I get the game to start up and since its written in an OS friendly matter, I can switch back to workbench and look at console output for 'printf style' debugging. But now I'm in a place where that doesn't work anymore. As soon as I try to start a new game, the exe crashes and takes down the whole Amiga (0x80000003), making it reboot - even if enforcer is running. Redirecting the exe output into a file is missing the crucial last part of the log - I guess due to file buffering. What are ways to debug things like that on the Amiga? I'm used to at least have a console and GDB :-) Can WinUAE somehow help? On a sidenote, how can I translate enforcer's Hunk/Offset hit data into a useful source/line output? I tried 'FindHit', but I think it does not work properly with the exe format that GCC produces (missing some LINE hunk?). I also tried using m68k-objdump to disassemble the exe and look at the proper offset, but it pointed into a completely unrelated function. Any debugging tips appreciated! |
08 January 2018, 03:14 | #2 | |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 881
|
Quote:
I haven't done it, but I understand you can use WinUAE's built in enforcer which might also be worth looking at ? |
|
08 January 2018, 05:28 | #3 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
That leads me to another question: how to make WinUAE provide a serial output to Windows, so I can attach a terminal to it?
|
08 January 2018, 08:58 | #4 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,515
|
Amga serial port can be redirected directly to a log window (-log -serlog) or it can be accessed using telnet (serial port GUI TCP option) or redirected to real serial port (serial port GUI COMx options)
But in this case easiest way is to enter debugger (shift+f12 or end+f12, note that gui debugger is unsupported so it may be good idea to also type xx to enter console debugger), check where exception 3 vector points (i) and set break point to exception 3 address (f <address>). JIT should be off. Run program (note that history collection slows down execution), breakpoint should activate, type H to see last 20 or so lines which hopefully helps to find out where and why it crashes. (It stores up to 500 previous instructions, H <number of lines>, HH also includes all registers). If CPU is 68020+, exception 3 is only generated when program jumps to an odd address. Another simple emulator debugging method is to write something to an address that no normal program does (like $100) and set memory watch point (w 0 <address> <length> <mode>, for example "w 0 100 1 w") = break when $100 is written. Useful when you want to break to debugger immediately before code you want to trace instruction by instruction (t). There is no debug symbol support. Maybe someday.. Functionally built-in enforcer-like UAE option and real enforcer don't have much difference. |
08 January 2018, 19:49 | #5 | |
Amigan
Join Date: Feb 2012
Location: London
Posts: 1,311
|
Quote:
Kinda old though. |
|
08 January 2018, 23:35 | #6 |
Registered User
Join Date: Jul 2009
Location: UK
Posts: 112
|
I would use asserts for each function to assure valid input. Most mistakes creep when functions are too complicated. Just try make function do one thing - correctly.
Use const on function input that would not change. Use abstraction to hide away complex pointers. |
09 January 2018, 02:29 | #7 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
Most bugs I ran in so far have been a result of mixing C and asm in the same project. C is compiled via GCC, the assembler Code via VAsm. Problems arise because the original project was done using SAS/C. Gcc and SAS/C use different calling conventions.
I got around most problems specifying the proper registers to the C prototypes directly. But it looks like gcc does not know about the d0/d1 a0/a1 as scratch Register Convention. Looks like I’ll have to write calling trampoline functions with gcc online assembly (providing input/output/clobber notation) |
09 January 2018, 19:34 | #8 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 719
|
gcc knows about the scratch registers. Can you provide a simple example?
|
10 January 2018, 21:15 | #9 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
Thanks Toni, I managed to get the debugging console working and also got the telnet serial connection up&running!
Ok, I think I have to retract my claim about the scratch registers for now. I do see sequences like this in the gcc produced code Code:
8874: 48e7 3030 moveml %d2-%d3/%a2-%a3,%sp@- Trying to come up with my own trampoline C functions that would call the assembly functions via GCC inline assembly (specifying the input/output/clobber registers) proved harder that I thought... in some instances GCC decided to remove my function call altogether (not blaming GCC here, you just need to know what your'e doing) An issue I did found, though, is that there were global function pointers delclared as Code:
extern fixed_t REGARGS (*FixedMul)(REGD0(fixed_t a), REGD1(fixed_t b)); extern fixed_t REGARGS (*FixedDiv)(REGD0(fixed_t a), REGD1(fixed_t b)); But the storage for FixedMul and FixedDiv was actually allocated in the assembler file: Code:
;----------------------------------------------------------------------- section __MERGED,bss ; pointers to CPU-specific FixedMul and FixedDiv routine _FixedMul ds.l 1 _FixedDiv ds.l 1 I added the definition of the pointers to C code and removed it from the assembly code and it started to work. Maybe GCC's linker doesn't know how to handle the __MERGED section? |
11 January 2018, 17:18 | #10 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 719
|
You probably have your reasons for choosing inline assembly....but, having the assembly functions in a separate .s file I've found works way better
|
12 January 2018, 00:01 | #11 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
That is what the code is doing. I am just trying to get the ADoom source compiled & working with the gcc tool chain. ADoom happens to implement some of the code in separate .s files, compiled with VAsm and linked into the project.
|
12 January 2018, 13:45 | #12 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,500
|
A real AmigaOS linker (alink, blink, slink, vlink, phxlnk, etc.) would usually know that sections named "__MERGED" should be merged together into a single combined data-bss section, so they can be accessed with a base-relative addressing mode via A4 (small data mode). The linker would also provide _LinkerDB to initialize A4 on startup.
I didn't look into the ADoom sources, but provided the assembler sources use the small data model (access static data via A4) you will probably run into a few problems. |
25 January 2018, 18:52 | #13 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
Another question to Toni: how to create a breakpoint in WinUAE to an exception that would normally cause a guru meditation? I'd like to find out about the code that caused the ecception.
|
25 January 2018, 20:53 | #14 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,515
|
Easiest is to check exception vector (i) and set breakpoint to exception address.
|
08 March 2018, 15:32 | #15 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
Quote:
|
|
08 March 2018, 15:56 | #16 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,002
|
If you want to debug on a classic Amiga I can recommend COP from Thomas Richter (THOR). Can step through interrupts too.
|
08 March 2018, 18:24 | #17 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
@bebbo: this is my repo
|
09 March 2018, 15:19 | #18 |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
|
12 March 2018, 11:42 | #19 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,515
|
Hopefully this is still on-topic enough..
What options does Amiga gcc have for generating debugging information? And how does it fit with hunk format executables? (at least hunk_symbol seems to be far too simple) I am finally trying to make UAE debugger more useful for developers (http://eab.abime.net/showthread.php?t=87499) and I'd like to include some sane debug symbol information support, preferably something that can also support at least partial source level debugging. (map binary offsets to code file/line) |
12 March 2018, 12:58 | #20 |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
-g generates old stab debug format. It contains enough information to map source lines to asm offsets and display variables.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Debugging? | MartinW | Coders. C/C++ | 10 | 03 January 2018 20:59 |
Debugging over Serial-Port | sigma63 | support.WinUAE | 1 | 14 March 2016 19:02 |
Remote C/C++ debugging? | alkis | Coders. C/C++ | 1 | 03 January 2014 12:17 |
Remote GDB debugging | copse | support.WinUAE | 6 | 31 August 2011 01:05 |
The enemy at the end of a level - strategies | Rick Dangerous | support.Games | 6 | 05 May 2006 12:58 |
|
|