Re: [RFC] Linux system call builtins

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 04/08/2024 06:19, Matheus Afonso Martins Moreira via Gcc wrote:
>     __builtin_linux_system_call(long n, ...)
...
> Calling these builtins will make GCC place all the parameters
> in the correct registers for the system call, emit the appropriate
> instruction for the target architecture and return the result.
> In other words, they would implement the calling convention[1] of
> the Linux system calls.

note: some syscalls / features don't work without asm
(posix thread cancellation, vfork, signal return,..)

and using raw syscalls outside of the single runtime the
application is using is problematic (at least on linux).

>   + It doesn't make sense for libraries to support it
> 
>         There are libraries out there that provide
>         system call functionality. The various libcs do.
>         However they usually don't support the full set
>         of Linux system calls. Using certain system calls
>         could invalidate global state in these libraries
>         which leads to them not being supported. Clone is
>         the quintessential example. So I think libraries
>         are not the proper place for this functionality.

i don't follow the reasoning here, where should the
syscall be if not in a library like libc?

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, but it is also
a syscall that only freestanding application can use
not something that calls into the libc, and even in
a freestanding application it is tricky to use right
(especially in a portable way or with features like
shadow stack), so i don't see why clone is the
quintessential example.

>   + It allows freestanding software to easily target Linux
> 
>         Freestanding code usually refers to bare metal
>         targets but Linux is also a viable target.
>         This will make it much easier for developers
>         to create freestanding nolibc no dependency
>         software targeting Linux without having to
>         write any assembly code at all, making GCC
>         ever more useful.

i think the asm call convention bit is by far not the
hardest part in providing portable linux syscall wrappers.

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, but i guess it's ok if
it is by default an error outside of -ffreestanding.