Free Pascal target Atari

[PeterS]

Good point.

It did have several compiler directives from the Pure Pascal build but I have been removing them because I assumed they would be incorrect or didn't exist in fpc.

[PeterS]

Would you expect gdb to work with fpc Atari binaries ?

I have gdb 5.0 installed and it's doesn't like the format.

[ThorstenOtto]

I'm not sure whether FPC can generate stabs debug info (which is required for that old gdb). Situation will change when the WIP mintelf toolchain is released, and FPC is using it. The new gdb will then use dwarf debugging information.

[ChainQ]

The short answer is no. The long answer is, for a starter, I think vlink strips all debug info during linking. If I remember correctly, it doesn't know how to encapsulate stabs debug info that is generated by FPC into an Atari binary. I could be wrong there though, I talked about this with Frank Wille, but I can't remember if it was for Amiga, or for Atari files. So we might need to support GNU Binutils there which is possible, but last time I ran into some issues with it, which is why I stuck to vlink/vasm. Also, i'm sure you'd need to recompile everything for that to work (can't use the same object files, most likely).

There might be other things that block it too. I never tried. I might, now that you reported it. Not sure what's the wrong format it complains about. We can switch also to DWARF, when the mintelf toolchain is complete, although I'm not sure of the other implications of that.

[ThorstenOtto]

I'm not sure how good the dwarf support in vasm/vlink is. In the binutils, we had to add some workarounds for the relocations, since on Atari, they must not be applied to odd addresses. Another major change is that it now uses dwarf exceptions, instead of the SJLJ expections used previously. That may require also some changes to the startup modules.

So all-in-all, it would be best to switch FPC to gas/binutils.

[ChainQ]

I don't think we can use DWARF exception tables right now with FPC on m68k, we use SJLJ everywhere. Neither we can/do link against C/C++ libs statically (on Atari). So the only direct consequence would be is having working debug info. All of this can be added of course, but I guess we have bigger problems first. Also, we do not need to "switch" as such, maybe if we talk about the defaults, we can support both assembler/linker pairs just fine.

BTW, do named sections and section garbage collection work with the new binutils? That was the main feature why I stuck to vlink/vasm. (So a hell world can be 20K, not 200K...

[ThorstenOtto]

I can't remember, but does FPC provide all library routines that normally come from libgcc? Such as long multiply, float functions etc. If that is the case, the you don't need to link against it of course. That would also mean that you still can use SJLJ exceptions, provided the unwinding is also handled by some FPC library.

And yes, named sections and garbage collection works of course, assuming you pass the needed flags to the linker.

[ChainQ]

Yes, the FPC RTL has our own floating point emulation, and similarly, provides longmul, longdiv, etc on a 68000. We can also compile 64bit math on our own, so do exception unwinding. So no, we do not link against any C code by default. (This is also true for say, Linux, where the kernel ABI is stable, so there's no need, until the application is single threaded.) So we do not use vlink/vasm because we piggyback any sort of C infrastructure from VBCC, but because they're very self-contained tools, and they're much easier and quicker to build, usually. (And it provided more modern features at the time of the decision.)

Actually, we already have some sort of a GNU binutils support, but as I had issues with it, I never cared to polish it up. I think the issue I had was, that for native (hosted on TOS) compiles, either AS or LD was crashing. Probably the later. Can't remember. Can you point me to a version, that I can try to compile on a macOS ARM64 host, and you think is "good enough" to start using?

[ThorstenOtto]

Precompiled versions (multiarch for x86_64/arm64) binaries are available at http://tho-otto.de/snapshots/crossmint/macos/. The mintelf toolchains there are not yet the last versions, but should generally work. The repo where those are built from is available at https://github.com/th-otto/crossmint/

You will also find several gcc versions there.

[PeterS]

What is the latest Atari gdb ?

[ThorstenOtto]

For a.out format version 5.1, from Vincents site. There is also one compiled from the current binutils repo (somewhere between version 13.0 and 14.0), available at http://tho-otto.de/snapshots/gdb/gdb-14 ... 020.tar.xz, but that only works with the new mintelf toolchains (binutils 2.41 & and gcc's from the snapshot archives)

[PeterS]

On the Freemint discord I asked how long filenames work in mint.

The gist of it is that pdomain(1) is used to enable long file names in the app. If it returns an error then long filenames are not supported.

Most of dos.pp and sysutils.pp would have to be modified in the posix style.

I'm still looking for/at the fpc code to see if I can figure out what would be involved.

[ThorstenOtto]

The gist of it is that pdomain(1) is used to enable long file names in the app. If it returns an error then long filenames are not supported.

That is not entirely true. Under MiNT, Pdomain() will never return an error (see https://github.com/freemint/freemint/bl ... #L242-L254). Same for MagiC. But it will of course return an error under SingleTOS where it is not implement at all.

Also it does not have much influence on long filenames. You can use functions like Dopendir() etc. regardless of the current domain. Only the minix fs seems to behave slightly different depending on domain, but not ext2fs or others. FAT partitions have a separate flag per drive whether they return long VFAT names.

[mfro]

IMHO, asking Pdomain() for long filename support is not the correct approach.

You'd probably rather do what tos.hyp says in its Dopendir() docs. Dopendir() + Dreaddir() + Dclosedir() will be required to support long filenames anyway.

The Dopendir() docs state the functions will be available with a MiNT cookie >= 0.90 (or Magic >= 3.0). So I'd rather check the cookies. Although not really relevant anymore, this would allow you to use long filenames in MiNT <= 1.04 (that introduced Pdomain()).

Regarding path length/truncation, Dpathconf() (requires MiNT >= 1.04) should be your friend.

[ThorstenOtto]

The Dopendir() docs state the functions will be available with a MiNT cookie >= 0.90 (or Magic >= 3.0). So I'd rather check the cookies.

The cleanest way would be to not depend on any cookie (MagiC also implements Dopendir) and just call Dopendir() and check the error code. Similar to what the POSIX opendir function in the mintlib does.