Debugging strategies

[pipper]

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!

[alpine9000]

Originally Posted by pipper

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 ?

[pipper]

That leads me to another question: how to make WinUAE provide a serial output to Windows, so I can attach a terminal to it?

[Toni Wilen]

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.

[nogginthenog]

Originally Posted by pipper

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.

[asymetrix]

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.

[pipper]

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)

[alkis]

gcc knows about the scratch registers. Can you provide a simple example?

[pipper]

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

    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

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:

;-----------------------------------------------------------------------
		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?

[alkis]

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

[pipper]

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.

[phx]

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.

[pipper]

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.

[Toni Wilen]

Originally Posted by pipper

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.

[bebbo]

Originally Posted by pipper

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

[Hedeon]

If you want to debug on a classic Amiga I can recommend COP from Thomas Richter (THOR). Can step through interrupts too.

[pipper]

@bebbo: this is my repo

[bebbo]

Originally Posted by pipper

@bebbo: this is my repo

Oh, ok
I only read

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.

[Toni Wilen]

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)

[bebbo]

Originally Posted by Toni Wilen

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.