@nokturnal
So while I have the tendency to just throw myself into complex stuff, that doesn't neccessarily mean that I know what I am doing :)
Basically, I started from the idea: "Huh, this shouldn't be too hard", and then had to learn and read up on a lot more stuff than I expected...
What I mean is: many of the things I have made is not based on choices, but more of a try and try again attitude.
So by saying that, lets go through your questins and see where that will get us.
ABI and fastcall:
I have not given any thought about fastcall, but apart from the gdbserver itself, that shouldn't be any problem to include.
Regarding ABI, my main goal have been to support just the very basic Atari binary executable formats - like .prg, .ttp etc.
Serial comm:
So, the serial comm is actually not being done through ACSI. Rather the same circuit that do the ACSI to SD, also do USB to RS232. The RS232 is connected to the Atari modem port.
I deliberately chosed this to make it possible to use any standard USE to serial cable and not impose the use of my hardware.
The real reason I made my own hardware from the beginning for ACSI to SD, is that at the time I started all this, the existing hardware options wre not up to my satisfaction.
Also, my solution also shares the Atari image on the SD card as a USB stick to a PC, so it simplifies moving the compiled binary to real Atari hardware.
I even support USB sharing of TOS formatted drives, something I think I am the first one doing.
Symbols:
Yes, I do support full symbolic debugging.
The way I do it is actually really simple:
The linking scripts used creates ELF files where the text, data and bss segments are packed in the exact same way that they will be in the PRG file.
So when doing remote debugging with gdb, gdb is told to use the debugging symbols from the ELF file.
When gdb then remote communicates with the gdbserver, it will do a "qOffsets" query that will return the addresses where the segments have been loaded.
This information is used by gdb to show you the correct memory addresses and symbols.
Mint cross tools:
I may have the wrong assumptions here, so correct me if I am wrong. But is it possible to build standard prg files that will run on any old Atari?
I had the assumption that you needed Mint to run them?
Anyway, I wanted to use the latest version of gcc that supported m68k, and using newlib is a very easy way to quickly support all C/C++ libs in one go.
In fact, you could write C++17 software that runs on an unmodified original 520ST with my toolchain.
Bindings:
Instead of writing bindings to all OS functions, I chosed to just add those needed at the moment. Reasoning that doing this all by myself, I needed to minimalize the work and not just add things that would stay untested for a long time.
For the sake of binary size, I have four different linker scripts that can be selected depending on your needs.
Those scripts also use different crts that will enable different functionality, like: if you don't use C++, then you don't need the crt to handle creation and deletion of global class instances.
Or if you just want to write a demo that doesn't care about nice entry/exit, then there is a script for that.
As an example, the current gdbserver binary using only C code, is 6409 bytes in size.
I really would love to see a working gcc toolchain with remote debugging for the Atari ST, and I am very open to discuss how to finalize that goal.
Also, sorry if I am a bit slow answering... I am recovering from a really nasty mental burnout a few years ago, so sometimes I just chose to not look at the computer for a while :)
And a little bonus clip:
https://youtu.be/icndB9psmBo?si=Nv5i7a3ovl3NfYK0
That is a proof of concept demonstration I did two years ago on a very unstable hardware and very bugged software.