> note: some syscalls / features don't work without asm > (posix thread cancellation, vfork, signal return,..)
That's true. On the other hand, POSIX compliance is not always a goal or a requirement. > and using raw syscalls outside of the single runtime the > application is using is problematic (at least on linux). I understand why their use is problem on other operating systems: since the ABI is not actually stable, programs will break eventually. Why do you say they are problematic on Linux though? Please elaborate. The ABI being stable should mean that I can for example strace a program, analyze the system calls and implement a new version of it that performs the same functions. > where should the syscall be if not in a library like libc? In the compiler. It should be able to generate the system call code. > clone cannot even be used from c code in general > as CLONE_VM is not compatible with c semantics > without a new stack (child clobbers the parent stack) > so the c builtin would not always work > it is also a syscall that only freestanding > application can use not something that calls > into the libc There are major projects out there which do use it regardless. For example, systemd: https://github.com/systemd/systemd/blob/main/src/basic/raw-clone.h https://github.com/systemd/systemd/blob/main/src/shared/async.h https://github.com/systemd/systemd/blob/main/src/shared/async.c https://github.com/systemd/systemd/blob/main/docs/CODING_STYLE.md > even in a freestanding application it is tricky to use right No argument from me there. It is tricky... The compiler should make it possible though. > so i don't see why clone is the quintessential example. I think it is the best example because attempting to use clone is not actually supported by glibc. https://sourceware.org/bugzilla/show_bug.cgi?id=10311 "If you use clone() you're on your own." > my main worry is that the builtins encourage > the use of raw syscalls and outside of libc > development it is not well understood how to > do that correctly I don't think their use should be discouraged. Linux system calls, at least. The ones of other operating systems most definitely should. Using them leads to breakage since the ABI is not stable. The developers of the go programming language can attest to that. > i guess it's ok if it is by default an error > outside of -ffreestanding. Hosted C programs could also make good use of them. They could certainly start out exclusive to freestanding C and then made available to general code if there's demand.
