Debugging?
 

General question...

If I'm writing in C and cross compiling (using gccv6), whats the generally accepted way of debugging program? Am I to assume that I copy it to real hardware and use a native debugger? In which case, any in particular?

At the moment on my native hardware (a GB-A1000 with 060) I am using StormC v3. I read a lot of bad things about it, but for someone just starting out, no matter how clunky it may be, the "IDE" is a great and fast way to get going. I've copied the install files for vbcc over to the machine but wasn't really intending to install it until something dictated the need.

I do also have FS-UAE running on the linux side of things that I use 75% of the time before trying on the real hardware.

Last night I had code that was crashing the minute I ran it on FS-UAE (software failure) so I built it on the Amiga with StormC but it didn't crash. It also didn't do anything, but it didn't crash. I tried to debug it, but of course, no crash meant that was kind of impossible.

The ideal would be remote debugging from within my linux based IDE (Jetbrains CLion). I'm sure I've seen remote debugging mentioned here in a search.

I know this is not what you'd like to hear, but....lot's of printfs.

The debugger in UAE is quite low-level. But when your knowledge of 68k-assembler is good, then this is an option. It doesn't offer much comfort, though. Its main advantage is to be able to debug low-level stuff, which is otherwise impossible to debug (because you have taken over the system, for example). Otherwise, better use a debugger on real hardware.

Most Amiga compilers can include symbols in the final executable (HUNK_SYMBOL). And also some compilers (including vbcc) support the LINE DEBUG hunks, introduced by SAS/C, which offer you some minimal source level debugging. A debugger would be able to show you the current source for the code you are debugging. Any additional debugging information is usually compiler/debugger-specific.

Be prepared that you have to debug your code on the 68k level, even with native debuggers. When you have some symbols to set a breakpoint on a function, you are already lucky.

I am using BDebug from the Barfly assembler package, which is a nice, system-compliant, AmigaOS debugger. It supports symbols and source level debugging via HUNK_DEBUG/LINE.

But Alkis is right. Most of the time printf is the easiest way to go. :)

Some programmers are using GCC 6 with vlink (vbcc linker) which should give Amiga HUNK format and allow BDebug (Barfly) and CPR (SAS/C) debugging. Maybe others have GDB working?

StormC v4 uses an old but good version of GCC.

GDB and CPR support remote debugging.

I prefer BDebug also for vbcc and SAS/C generated executables.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

Also use enforcer-like program to instantly detect most invalid/null pointers. And in emulation you can also enable invalid access logging in addition to other debugging tools.

Thanks everyone for the comments. For a noob to the Amiga programming world there's a lot to take in and read up on but I have a good basis now for doing just that. All I need is time now :D

I'm a programmer of 25 years for a living incidentally so I'm no stranger to printf debugging - indeed even in the world of modern IDEs that we live in it's not uncommon that I have to resort to that. It simply didn't occur to me that using printf's would automatically pop open a window with STDOUT in it.

This is related: http://eab.abime.net/showthread.php?t=80894

Nice - that's an interesting way of tackling things. I'm not so interested in being able to see the Amiga programs output in the Linux term because, let's face it, if I'm running the program on the Amiga (real or emulated) then I can see it in the window on the Amiga just as easily (split screen or multi screen).

What had already occurred to me however was to write a small resident program on the Amiga side which listened to the serial port and waited to be told what to do. Commands could be things like "run this program". That way my Linux build script can write it's output to a folder that is mapped on the Amiga to "PCDATA:" and then a command can be sent over serial to tell the Amiga to run it. Another command could tell it to kill it.

Only works if the program you want to remotely run doesn't take over the OS of course, and a lot of this is pointless if the program you're writing for the Amiga requires user interaction, because then you'll have to switch to the Amiga and input stuff anyway.

All useful info however!

You can run an Amiga shell over a serial connection and send shell commands. Not sure how you would kill a process but I'm sure there is a tool out there (Scout?). Or you can do it over a TCP/IP if your Amiga is networked.

BTW, what is the status of GDB on the Amiga? I saw a GDB stub for AROS but I never tried it.

The only version I have been able to dig up:
http://aminet.net/package/dev/gg/gdb-bin

Maybe the last.