Compatibility

Go standard library support

The GOOS=tamago target maintains full language and standard library support, stdlib is tested using original distribution tests, status is tracked through a tamago-go GitHub workflow:

Distribution tests are executed by mocking the required runtime support, implemented with bare metal drivers under GOOS=tamago, with a bridge to standard Linux system calls.

The testing environment for AMD64, ARM, ARM64 and RISCV64 architectures runs under Linux natively or using qemu-user-static via binfmt_misc.

The following test runs can be executed within a built TamaGo compiler on a natively supported architecture or cross-compiling with the relevant GOARCH override.

Standard distribution tests:

GO_BUILDER_NAME=tamago GOOS=tamago bin/go tool dist test

##### Testing packages.
ok      archive/tar     0.098s
ok      archive/zip     0.054s
ok      bufio   0.033s
...
ok      crypto/x509     0.226s

ALL TESTS PASSED

Individual package(s):

GOOS=tamago bin/go test -tags fakenet,user_linux runtime net crypto/tls
ok      runtime 2.504s
ok      net     0.862s
ok      crypto/tls      0.218s

Note

the fakenet tag is required for testing individual packages making network API calls,
the user_$GOHOSTOS tag is required to enable OS system call bridging, currently only user_linux is supported.

Warning

runtime flags (e.g. -run) are ignored due to lack of os.Args support under bare metal, for this reason -test.short is always assumed

Go application limitations

Most applications and libraries are not limited under GOOS=tamago, the following caveats apply:

• Asynchronous preemption for Goroutines is not supported, for this reason on single-core platforms scheduler starvation should be avoided.

  In such cases, just like Go js/wasm, blocking functions which are not executed in a new goroutine, while no other goroutine is running, will cause a deadlock (similar to this and this). As long as you never sleep in your main function without anything else going on this is quite natural to avoid.

• Due to the intrinsic nature of a bare metal application: there is no OS, there are no users, there are no signals, there are no environment variables. These are intended to be seen as featurs, rather than limitations.

• Applications which import packages that rely on unsupported system calls may not compile or work as expected (for instance terminal prompt packages will not be able to access syscall.SYS_IOCTL).

• Cgo is not supported.

• On GOOS=arm care must be taken with direct or indirect (e.g. dependencies) use of the atomic package due to the last of these bugs. This is a generic Go issue not specific to TamaGo but possible on the supported 32-bit target.