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.
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.
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.
When using syscalls directly, it does not matter. Kernel doesn't care how your laid out your userspace stack.
Except when it does: https://github.com/golang/go/issues/20427
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)
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).
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.
I hope they're planning to fix that...
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.
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/
Although I never checked so I could be completely wrong, I would expect folks shipping just kernels like SeL4 to ship stable kernel ABI rather than a libc.
Yes and this is by design, out of necessity, taught by experience. Commercial customers back in the day paid lots and lots of money, so solutions had to be found and they had to work.
With that being said, I disagree with your characterization of “some header”–anything that’s in Apple’s headers is public API, whether it has a fancy page on developer.apple.com or not. Apple has a very clear definition of what they consider to be “private”, and anything in /usr/include isn’t it.
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/syscall.h #ifdef __APPLE_API_PRIVATE
...
#endif /* __APPLE_API_PRIVATE */https://github.com/golang/go/commit/02118ad0a0cacb00c1d834b3...
In fact, come to think of it, Linux is the only OS where syscalls are the official public userspace API, is it not? On all other platforms, they're an implementation detail behind the system libraries.