October 4, 2016 by Ed Schouten
When CloudABI was initially released back in March 2015, we only provided support for using it on x86-64 (modern Intel/AMD) systems. Support for a second architecture, ARM64, was added soon after in July 2015. Today we are glad to announce that CloudABI is now available for two more architectures, bringing the total to four!
Though 64-bit Intel/AMD CPUs have been available for quite some time, it turns out that many operating system development hobbyists still make use of its 32-bit counterpart. Reasons are that some consider it easier to use and documented more thoroughly, especially by Wikis such as OSDev.org. Earlier this year, one member of our community, Sjors Gielen, expressed interest in using CloudABI as part of his IA-32 based capability-based operating system. Together with Sjors, we’ve now ported CloudABI over to this architecture.
Porting turned out to be relatively easy. On the kernel side, CloudABI
already has a pretty clear distinction between system calls that don’t
assume a specific pointer size and ones that do. FreeBSD, for example,
has this code stored in separate directories, called
respectively. Providing support for 32-bit flavours was mostly a matter
On the userspace side, adding support for this 32-bit platform was a
very good opportunity for us to shake out some portability bugs in the C
library. The most subtle one we encountered was a typo
that prevented the creation of program arguments (
argdata_t) of type
integer having a value greater than 2³².
Obtaining a toolchain for IA-32 was of course easy to accomplish. CloudABI recently switched to LLVM’s linker LLD exclusively. A nice feature of LLD is that it requires no configuration for cross building. It automatically determines its target architecture based on its input files. LLD worked perfectly fine in our case, except for a small bug related to TLS relocations. Fortunately, the fix for this bug has made it into the tree just in time for LLVM’s 3.9.0 release, meaning CloudABI for IA-32 can now be targeted using an unmodified copy of LLVM.
CloudABI’s support for IA-32 should now be on par with x86-64. The 32-bit executables can be run both on FreeBSD/i386 and FreeBSD/amd64. As IA-32 doesn’t allow for efficient position independent executables, there are no plans to provide support for emulating these executables from userspace, like we do on macOS. We advise that 64-bit executables are used for those purposes instead.
After getting CloudABI to work on one 32-bit platform, the next logical step was to extend our existing ARM port to work on 32-bit CPUs as well. Looking at the hardware in use today, I decided it makes most sense to just focus on CPUs implementing at least the ARMv6 instruction set and having a hardware floating-point unit. Commonly used boards like the Raspberry Pi all meet these requirements.
What makes ARMv6 different from all of the other supported hardware architectures is that it supports floating-point numbers only up to 64 bits in size (double-precision floating-point values), whereas the other architectures also support either 80-bit or 128-bit values. The math library used by CloudABI’s C library, OpenLibm, was not written with this in mind. For this reason, we’ve switched over to using the math library of musl libc instead. This math library not only supports ARMv6 out of the box, the code also seems to be of a much higher quality in general.
For ARMv6 we’re now in a state where we can get all of cloudlibc’s unit tests to pass. Unfortunately, we cannot yet declare ARMv6 to be on par with the other architectures, for the reason that LLD’s support for 32-bit ARM CPUs is still incomplete. Features like thread-local storage and C++ exceptions currently don’t work as expected. Looking at the pace at which LLD is being developed, it is very likely that these issues are addressed before the next release, so stay tuned!
Some of you may have noticed that I recently started working for one of my previous employers, Kumina bv. Being interested the direction in which CloudABI is going, Kumina offered me a job that allows me to spend a fair amount of time to continue its development. The work presented in this article is the first result of this.
I would hereby like to thank my colleagues at Kumina for their support!