Re: Re: [RFC] Linux system call builtins

[Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>]

> 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.