English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 08 January 2018, 02:38   #1
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 83
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!
pipper is offline  
Old 08 January 2018, 03:14   #2
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by pipper View Post
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!
You can use serial output for printing debug info. I haven't tried with winuae, but with fs-uae I output stuff to the serial port and use the fs-uae serial port emulation stuff to capture.

I haven't done it, but I understand you can use WinUAE's built in enforcer which might also be worth looking at ?
alpine9000 is offline  
Old 08 January 2018, 05:28   #3
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 83
That leads me to another question: how to make WinUAE provide a serial output to Windows, so I can attach a terminal to it?
pipper is offline  
Old 08 January 2018, 08:58   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,766
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.
Toni Wilen is offline  
Old 08 January 2018, 19:49   #5
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 624
Quote:
Originally Posted by pipper View Post
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?).
Try GccFindHit: http://aminet.net/package/dev/gcc/GccFindHit-1.2
Kinda old though.
nogginthenog is offline  
Old 08 January 2018, 23:35   #6
asymetrix
Registered User

 
Join Date: Jul 2009
Location: UK
Posts: 80
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.
asymetrix is offline  
Old 09 January 2018, 02:29   #7
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 83
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)
pipper is offline  
Old 09 January 2018, 19:34   #8
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 47
Posts: 431
gcc knows about the scratch registers. Can you provide a simple example?
alkis is offline  
Old 10 January 2018, 21:15   #9
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 83
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@-
and it never seems to push/pop d0/d1/a0/a1

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));
Which were later hooked up to assembler-implemented functions.

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 don't know exactly what happened, I didn't see any linker errors. But somehow the system got confused, jumped into nirvana and caused illegal instructions.
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?
pipper is offline  
Old 11 January 2018, 17:18   #10
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 47
Posts: 431
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
alkis is offline  
Old 12 January 2018, 00:01   #11
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 83
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.
pipper is offline  
Old 12 January 2018, 13:45   #12
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,165
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.
phx is offline  
Old 25 January 2018, 18:52   #13
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 83
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.
pipper is offline  
Old 25 January 2018, 20:53   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,766
Quote:
Originally Posted by pipper View Post
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.
Easiest is to check exception vector (i) and set breakpoint to exception address.
Toni Wilen is offline  
Old 08 March 2018, 15:32   #15
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 297
Quote:
Originally Posted by pipper View Post
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.
have a look there: https://github.com/mheyer32/ADoom
bebbo is offline  
Old 08 March 2018, 15:56   #16
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 740
If you want to debug on a classic Amiga I can recommend COP from Thomas Richter (THOR). Can step through interrupts too.
Hedeon is offline  
Old 08 March 2018, 18:24   #17
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 83
@bebbo: this is my repo
pipper is offline  
Old 09 March 2018, 15:19   #18
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 297
Quote:
Originally Posted by pipper View Post
@bebbo: this is my repo
Oh, ok
I only read
Quote:
I am just trying to get the ADoom source compiled & working with the gcc tool chain.
and you current state is way better than "trying", so I mentioned it.
bebbo is offline  
Old 12 March 2018, 11:42   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,766
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)
Toni Wilen is offline  
Old 12 March 2018, 12:58   #20
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 297
Quote:
Originally Posted by Toni Wilen View Post
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)
-g generates old stab debug format. It contains enough information to map source lines to asm offsets and display variables.
bebbo is offline  
 


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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:31.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.10143 seconds with 13 queries