Setting up a debugging environment for Bebbo's Amiga GCC toolchain

[Nightfox]

Hi all

I have not found a guide on how to do this so I'd like to ask it here.

How does one set up a proper debugging environment if compiling programs with Bebbo's GCC toolchain? By that, I mean being able to set a breakpoint and step through code in Visual Studio Code which is connected to a remote gdb session on either an emulated or a real amiga over the network?

So far I have had to put up with all my debugging being in printf() statements but I would like this to change!

Heck, now that the recent version of AmigaSSH has an SSH daemon, in theory it would be possible to get VSCode to get an amiga to run the app automatically

[pipper]

You can debug applications compiled with Bebbo’s gcc using his „bgdbserver“ tool.
Run it on the target machine to run your target app:
bgdbserver myapp

Then connect to the Amiga with m68k-AmigaOS-gdb in your toolchain’s bin directory. The port is 2345.
Compile and link your app with -g to produce debug symbols. The application on the target machine can be stripped. Provide the unstripped executable to gdb to get source level debugging.

I had mixed success with this setup. In my experience it’s rather flakey (I’m using it with the QtCreator IDE). You can only debug applications - the debugger doesn’t understand jumping into libraries, so you can’t debug a library call. Debugging into OS functions in ROM is also not doable, since single stepping requires the debugger to change the code on the fly. You need a network stack and thus can’t debug anything that disables the OS. A process spawning child processes or helper tasks cannot be debugged either. Randomly stopping the running process does often not work and hangs the debugger instead.
On the Amiga you often want to answer the question: my app crashes somewhere - where does that happen? The debugger is often not robust enough to survive the crash or cannot tell you where it happened, because the callstack is deep in some OS function. Or let’s assume the app is waiting for some IO or signal to finish. The debugger often won’t be able to stop the app because the callstack is again deep inside some ROM function. It can’t tell you where your program hung and therefore has limited usability.
Bgdbserver is open source. Maybe it’s possible to make it much more robust using MMU tricks and feed it with knowledge about libraries via FD files, let the debugger scan the system for open libraries and their bases as well as patch OpenLibrary/CreateTask to be notified when libraries get opened, new processes started etc… I wonder if the OS could provide better debugging support?

So far KPrintF proved to be the most robust debugging method. It’s very slow and tedious, though.

[NovaCoder]

LoL same here, my code is always full of logging.

It once took me 6 bloody months to find out what was causing a memory allocation issue in scummvm

[paraj]

I haven't tried getting the setup described in the OP working, but I can say that I have had luck (though it's by no means neither perfect nor painfree) getting proper debugging working with WinUAE as detailed in this long thread: https://eab.abime.net/showthread.php?t=91321

If you have an otherwise well-behaved C program, it's definitely worth checking out. Most of the issues I had (apart from a painful setup experience) were due to assembler code modifying variables in in code sections, which shouldn't happen for most C stuff.

Certainly no replacement for full GDB experience but tracking down e.g. memory leaks should be easier.