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