> There is quite a bit of variance in how the kernel is entered. I assume you mean the vDSO. It is also documented and stable.
https://www.kernel.org/doc/html/latest/admin-guide/abi-stable.html#vdso > Unless otherwise noted, the set of symbols with any given version > and the ABI of those symbols is considered stable. > It may vary across architectures, though. > As of this writing, this ABI documentation as been confirmed > for x86_64. The maintainers of the other vDSO-using architectures > should confirm that it is correct for their architecture. It is an also entirely optional. The architecture specific system call entry point is always available. The vDSO exists to provide much more efficient ways to access frequently queried system information such as the current time. While the optimized approaches are preferable, the slower system call entry points are still available and stable. > On x86-64, one once popular mechanism > is longer present in widely-used kernels. Please elaborate. Do you mean the vDSO? Linux places a pointer to the vDSO in the auxiliary vector, and a pointer to that vector is located immediately after the program's environment. The program will have to walk that vector in order to find the vDSO. If the vDSO is missing, then the program will fail to find that pointer and hopefully fall back to traditional system call entry points. Perhaps GCC could also have builtins for accessing things like argc, argv, envp and auxvec. They are part of the ABI too. This would allow programs to access the vDSO via the auxvec. It'd also allow implementation of ELF entry points entirely in C. > But using a builtin obfuscates that relationship. > There is no __builtin_call_ms_abi, is there? That's true but that's because there's no need for those builtins. Functions which conform to specific ABIs will have been marked with the relevant attribute so GCC will know how what to do when it is called. Linux system calls do not actually exist as functions so they can't be marked that way. It could be implemented that way by having a naked system call function whose entire body is just the syscall instruction. Then it could be marked with a linux_syscall_abi attribute and the compiler would know to where to put the arguments and from where to obtain the return value. That just replicates what the builtin is supposed to do though. The builtin would not need any declarations or attributes. It would just work.
