Re: [RFC] Linux system call builtins

[Andrew Pinski <pinskia@gmail.com>]

On Mon, Apr 8, 2024 at 11:20 AM Paul Iannetta via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
> On Mon, Apr 08, 2024 at 06:19:14AM -0300, Matheus Afonso Martins Moreira via Gcc wrote:
> > Hello! I'm a beginner when it comes to GCC development.
> > I want to learn how it works and start contributing.
> > Decided to start by implementing something relatively simple
> > but which would still be very useful for me: Linux builtins.
> > I sought help in the OFTC IRC channel and it was suggested
> > that I discuss it here first and obtain consensus before
> > spending more time on it since it might not be acceptable.
> >
> > I'd like to add GCC builtins for generating Linux system call
> > code for all architectures supported by Linux.
> >
> > They would look like this:
> >
> >     __builtin_linux_system_call(long n, ...)
> >     __builtin_linux_system_call_1(long n, long _1)
> >     __builtin_linux_system_call_2(long n, long _1, long _2)
> >     /* More definitions, all the way up to 6 arguments */
> >
>
> As noted by J. Wakely, you don't need to have one variant for each
> number of arguments.  By the way, even if you have multiple variants
> you could unify them all under a macro __builtin_linux_system_call by
> means such as "overloading macros based on the argument count." [1]

Actually you don't need a macro if implemented inside GCC. Can you can
count the number of arguments and expand it based on that. No reason
for macros. Now the question comes is the argument long or some other
type? E.g. for some 32bit ABIs built on top of 64bit ISA might always
just pass 32bits or they might allow passing the full 64bits. (x32
might fall under this and MIPS n32). Or do you split a 64bit argument
into the lower and upper half registers. Maybe you should warn/error
out if not passed the correct sized argument.
Also do you sign or zero extend a 32bit argument for LP64 targets?
Right now it is not obvious nor documented in your examples.



Thanks,
Andrew Pinski

>
> > 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.
> >
> > I'm often asked why anyone should care about this system call stuff,
> > and I've been asked why I want this added to GCC in particular.
> > My rationale is as follows:
> >
> >   + It's stable
> >   [snip]
>
> I assume you're talking about the interface which is often abstracted
> by functions such as the following which are often found in libcs or
> freestanding libraries. The musl is a typical example (cf syscall_arch.h)
> for each architecture ( https://git.musl-libc.org/cgit/musl/tree/arch )
>
> long linux_system_call_1(long number, long _1)
> {
>         register long rax __asm__("rax") = number;
>         register long rdi __asm__("rdi") = _1;
>
>         __asm__ volatile
>         ("syscall"
>
>                 : "+r" (rax)
>                 : "r" (rdi)
>                 : "rcx", "r11", "cc", "memory");
>
>         return rax;
> }
>
> >
> >   + It's a calling convention
> >
> >         GCC already supports many calling conventions
> >         via function attributes. On x86 alone[3] there's
> >         cdecl, fastcall, thiscall, stdcall, ms_abi, sysv_abi,
> >         Win32 specific hot patching hooks. So I believe this
> >         would not at all be a strange addition to the compiler.
>
> I may be wrong, but I think that at least on sysv x86_64, syscalls have
> the same calling conventions as regular functions.  However, the
> function descriptor is not an address (or a symbol reference) but a
> number.
>
> >
> >   + It's becoming common
> >  [snip]
> >
> >   + It doesn't make sense for libraries to support it
> >  [snip]
>
> At least, it would be nice if not all freestanding libraries had to
> reimplement those syscalls stubs.
>
> >
> >   + It allows freestanding software to easily target Linux
> >
> >   + It centralizes functionality in the compiler
> >
> >   + It allows other languages to easily target Linux
> >
> >   + Compilers seem like the proper place for it
>
> I tend to agree with those points.
>
> > Implementation wise, I have managed to define the above builtins
> > in my GCC branch and compile it successfully. I have not yet
> > figured out how or even where to implement the code generation.
> > I was hoping to show up here with patches ready for review
> > but it really is a complex project. That's why I would like to
> > to see what the community thinks before proceeding.
> >
>
> I think you could have a look at the function 'expand_call' in
> calls.cc to see how regular calls are expanded to RTL and see what you
> would need to do to support calls which use a number rather than an
> address.
>
> Cheers,
> Paul
>
> [1]: https://jadlevesque.github.io/PPMP-Iceberg/explanations#overloading-macros-based-on-argument-count
>
>
>
>