Tier System: `x86_64-freebsd`

[andrewrk]

https://github.com/ziglang/zig/issues?q=is%3Aissue%20state%3Aopen%20label%3Aarch-x86_64%20label%3Aos-freebsd

Tier 1

• All non-experimental language features are known to work correctly.
• The compiler can generate machine code for this target without relying on LLVM.
  • x86 backend on FreeBSD fails to link #25075
  • test-link fails randomly(?) on FreeBSD #25323
• The CI machines automatically run the module tests for this target on every push.

Tier 2

• The standard library's cross-platform abstractions have implementations for this target.
• This target has debug info capabilities and therefore produces stack traces on failed assertions and crashes.
• libc is available for this target even when cross-compiling.
• The CI machines automatically build the module tests for this target on every push.

Tier 3

• The compiler can generate machine code for this target by relying on an external backend such as LLVM.
• The linker can produce object files, libraries, and executables for this target.

Tier 4

• The compiler can generate assembly or C source code for this target.

[bnoordhuis]

get my raspberry pi (aarch64) hooked up to the CI somehow

That's a raspberry pi 3? We have a small armada of those in the Node.js CI. They're a lot faster than the pi 1 and 2 but still so much slower than regular server hardware that we cross-compile and shard the test suite across 10 or 12 machines.

That's a long-winded way of saying they're not really an option unless you're really patient. :-)

[andrewrk]

That's a raspberry pi 3?

Yes it is. Thanks for the heads up!

[valpackett]

re: CI, I'm "starting" a buildbot cluster at https://porting.club — currently it's just a Scaleway 4-core ThunderX VPS (the master as well as the first worker, which is a jail on the same box).
The "plan" is to have a cluster with many different OSes and CPU architectures specifically for stuff that has portability needs — compilers/interpreters/VMs, libraries that touch OS specific stuff, etc.
The idea is to not use throwaway containers or VMs, but instead set up persistent environments — so that they can be used not just for CI tests or nightly builds, but also for development (i.e. project developers should be able to ssh into the workers).

(btw ThunderX cores are comparable to Cortex-A72s / significantly faster than the A53s the RPi has)

(@bnoordhuis I guess Node.js builds its own copy of V8, while Zig wouldn't need to build any monster dependencies, and the compiler itself is kinda lightweight. Oh wait, LLVM can be a memory hog though, and the Pi only has 1GB.)

[andrewrk]

@myfreeweb that's exciting. Keep me updated.

In other news I updated the support table in the README to use a "tier" system: https://github.com/ziglang/zig#support-table

I think what I'll do is review the freebsd2 branch, make any changes that I see fit, and then merge it into master. Then freebsd becomes Tier 2 for x86_64 and i386. And then this issue can remain open to track Tier 1 support.

[andrewrk]

I just merged the freebsd2 branch into master, and so now FreeBSD has Tier 2 Support. This issue is tracking the effort to achieve Tier 1 Support.

[ararslan]

FreeBSD is now available on Cirrus CI. I set it up on one of my repositories to test it out. As an example, you can see the config here and a build log here.

[andrewrk]

I rented a freebsd server for an hour and poked at it. Here's what I accomplished:

• Fixed bug in os_self_exe_path which was making the build cache not work
• Fixed a bunch of incorrect declarations in std/os/freebsd/index.zig. For example NSIG was copied from linux and it was incorrect. Be careful copying this stuff from other systems, we have to hand-verify that the declarations are correct for every single one that we add. Also the Sigaction struct was knowingly incorrect. I didn't catch this in the pull request. Similarly some syscall functions returned success even though they did nothing. I removed these. I think it's better that they are compile errors until we can have the actual implementations for them.
• Implemented raise syscall and hence made abort work. I might have found a bug in freebsd libc: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-December/053712.html Depending on the answer to that mailing list question, we need to add signal handling protection in raise or abort.
• Updated syscall code and fixed some bugs

Now Hello World works and the behavior tests pass in debug mode. ReleaseFast mode doesn't pass, and the standard library tests require more porting work in order to compile. But they're in a state where I think it's easy to contribute to.

[andrewrk]

One of the developers from FreeBSD stopped by and clarified that the stable kernel ABI is in fact through libc, and so we will now switch to doing it that way, like we do for MacOS.