You can achieve that on other OSes too though, still without requiring libc.

For instance, on Windows the syscall API is hidden and changes from release to release, but KERNEL32.DLL persists as the stable system API that you're supposed to call.

Linux desperately needs to get past the notion that libc is the only gateway to the kernel, and instead start supplying a standardized "system/kernel" user-level wrapper library. One which wraps the syscalls nicely but doesn't try to add additional language-specific functionality like printf or memcpy.

> Linux desperately needs to get past the notion that libc is the only gateway to the kernel,

Are you sure about that? Linux doesn't have that notion, it keeps the syscal ABI stable, and anyone can use it directly, like Go does. There's no need to go through blessed syscall library, which on their respective systems are the only gateway to the kernel.

The biggest advantage is that it lets other OS easily impersonate linux e.g. SmartOS or Windows can provide kernel-level "linux persona" and have an unmodified linux userland run on top.

They can do right now. Both the API and ABI are very rarely (read never but very problematic bugs or similar) broken in a backwards way.

That's my point. It's only possible with Linux because Linux provides a stable kernel ABI. You can't impersonate Windows or OSX the same way.

But you can impersonate Windows by providing your own implementation of the Kernel32 API. What's the essential difference between that, and emulating syscall API?

Ahh sorry, I understood the other way around :)

On Windows, kernel32.dll is basically the Windows equivalent of libc - it's still a userspace library that wraps syscalls, and you're not supposed to use them directly.

But I don't see why it's a problem, either. What's the actual benefit of Go invoking syscalls directly on Linux? That it doesn't depend on glibc? But that is only an advantage because glibc is not guaranteed to be there on Linux, the way e.g. kernel32 is on Windows. If it were, there'd be no reason to not use it.

Specifically Go has very particular ideas about memory and stack layout, which do not go well with C libraries. In order to call a C library, Go has to go through thunking shims.

When using syscalls directly, it does not matter. Kernel doesn't care how your laid out your userspace stack.

> Kernel doesn't care how your laid out your userspace stack.

Except when it does: https://github.com/golang/go/issues/20427

IIRC this was because of a rather amusing behaviour of a Gentoo toolchain with some hardening patches, in this case doing a bit of fun on the stack to make sure it's safe.

A lot of the hardening patches come with disclaimers that some software might break, and as shown by this bug, for good reason.

I'd rather blame the compiler patches for this silly behaviour (and maybe the kernel for not documenting and limiting how much stack VDSO can use)

It's not really obvious to me that the original issue, mentioning os.Exec calls and Ubuntu versions, has the same cause as the crashes from the commenter mentioning patched Gentoo toolchains.

"libc" is the C-language runtime library. The Go language is not the C language. Different things are different. There is no reason for programs written in the Go language to use the C-language runtime in any operating environment, any more than there is a requirement for all programming languages to use curly braces to delimit lexical scope.

> That it doesn't depend on glibc? But that is only an advantage because glibc is not guaranteed to be there on Linux, the way e.g. kernel32 is on Windows. If it were, there'd be no reason to not use it.

Yes - but it's an advantage because glibc is a compatibility nightmare. One of Go's really nice features is that you can compile a binary and it will run pretty much anywhere. That would be pretty much impossible if it linked with glibc (even if you ignore the fact that glibc might not be present).

Not true. On Solaris (and Windows), and more recently in macOS as well we link with libc (or equivalent), and we can still cross compile from any system to these systems. It's not a free lunch of course, doing raw system calls would be preferable, for many reasons.

I implemented support for this, for ELF, when I wrote the Solaris port. Other people have done it for PE and Mach-O. It is a fallacy to think that you need access to a shared library in order to link with it. That's only true for C toolchains that don't know better. For Go we have our own toolchain and it doesn't have such a restriction.

This is one of the points lost to the "why didn't you just use LLVM?" crowds. Our own toolchain allows us flexibility that simply doesn't exist with traditional toolchains.

How do you handle changes to the kernel? Can your binaries run on any macOS version or only the very latest? This sounds really cool but also super dangerous. Apple is not known for providing a stable ABI :)

You got it backwards, Go used to do raw system calls on macOS, and binaries were occasionally broken by kernel updates. Now Go uses libc on macOS, and binaries are forward compatible with future macOS versions just like any other C/C++/ObjC/swift program. OS X 10.10 (Yosemite) is the current minimum supported version.

Unfortunately, Go still insists on using syscalls on the BSDs, despite them not being a stable (between major releases) API there either.

I hope they're planning to fix that...

Ok nice! In many ways it would be cool if apple had a stable interface for XNU like we do in Linux.

This used to be true, Unfortunately it’s not now.

I found this out when trying to copy a go program I had compiled on alpine to an Ubuntu machine and got the “file not found” error from the linker. :(

Try it yourself: run ldd on a recent go binary.

Go uses the glibc for DNS resolution by default, if you set CGO_ENABLED=0 during compiling it should result in a static binary.

As the article eludes to it is not without its challenges, however. As an example see this issue: https://github.com/golang/go/issues/1435 which goes into some of the details why implementing a call for setuid() is not straightforward without the knowledge built into glibc.

Also the trickiness of having efficient process fork/exec based on vfork: http://ewontfix.com/7/ and the considerations going into Go: https://go-review.googlesource.com/c/go/+/46173/

I think for setuid in particular the right fix is for the kernel to provide a new syscall that operates on the whole process. The current hoops that glibc has to jump through with signals are complicated (and maybe racy? it's been a while since I looked at the code) and tie up a signal for libc's private use; better support at the kernel layer would allow that to all be eventually dropped.

( allude (elude means escape))