4 ms·
I believe the impetus for Golang was macOS and Windows, rather than the BSDs. It’s not that libc is used to fix kernel problems/compatibility issues, but rathe
by catiopatio 4y ago
I believe the impetus for Golang was macOS and Windows, rather than the BSDs.
It’s not that libc is used to fix kernel problems/compatibility issues, but rather, the kernel ABI is not a supported, stable public API.
On macOS, there are cases where using the syscall ABI directly will result in your code breaking when interacting with any other code that does correctly use libc, due to out-of-sync userspace state maintained by libc.
For example, the fork(2) implementation in macOS’ libSystem will invalidate the cached copy of the current process’ pid used by getpid(2).
If you fork(2) by directly trapping to a syscall, the cached pid won’t be invalidated; any future calls to getpid(2) through libSystem will return the stale pid.
- glandium 4y agoThings like this are true on Linux too. Don't call the clone syscall manually because it will mess up with glibc internals.
- iainmerrick 4y agoBut only if you’re also using glibc, right? If you’re only using syscalls and no libc at all, you’re fine (on Linux, and only Linux).
- glandium 4y agoIf you're only using syscalls on macOS, you're fine too, as far as libSystem is involved. You're not fine if newer kernels change the syscall ABI, though.
- matheusmoreira 4y ago> But only if you’re also using glibc, right? Yes. As a glibc maintainer once said, if you use clone you're on your own. And that is fine.
- codeflo 4y agoYes, I believe what language implementation would want to do is to use the lowest-level API that’s supported and stable. On Linux, that happens to be syscalls, on BSD and macOS, that’s libc, and on Windows, that’s the so-called “Win32” API (kernel32.dll and such).
- wongarsu 4y agoMeanwhile Windows makes no effort at all to keep syscall numbers stable, because you aren't supposed to use them directly. For example NtCompleteConnectPort has changed id five times in Windows 10 alone. Meanwhile OpenBSD was discussing ideas to extend their system-call-origin verification to only allow syscalls from libc.
- dom96 4y agoWhat's the motivation for Golang targeting syscalls directly? Is it just to avoid the libc dependency?
- chc 4y agoI'm not sure it was libc in particular. In general, the Go compiler's initial design was very enthusiastic about the idea of fully statically linked binaries and easy cross-compilation. Avoiding system libs does kind of flow naturally from those goals.