From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 6D83C3858D28 for ; Mon, 8 Apr 2024 18:26:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D83C3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6D83C3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712600821; cv=none; b=waILP4sgXGTvEdT4NLBPx4lmW3iDLQ7ETG8yKuq7Ox4xsfWdPE1eZm32wgk0DBgsdJ9oUBaxFr0I8G4IqrWjUWCzICSldvYMRrG8MWT48wA5l5I8umKsB3f9Mmemsgw8m5PxCDmXYAqYJ69yrZcTrn04sv5FgftzihLJkM9af0E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712600821; c=relaxed/simple; bh=B+Oq3cDkgigYjwav/KR7TpolPhWw2XlPCuOqqr9ljkA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=AxqGoI32jyP8Pc5JS1PEn3Yzo24CjrbTwLcIoDc1OeOeuoe/i7g6NcIRAjMxkPrNGQjPtXSRcpxvonAR3hc7y/rcYTqHKBFVImgWo0gu3SDuvhlT4nLDB1WuYYvfh/pMqdyllBeusaNN7IfLe5pmt2NfpSogN9XJCOTlG4hB2jk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2a484f772e2so1987537a91.3 for ; Mon, 08 Apr 2024 11:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712600812; x=1713205612; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hGV1LeAXva9vwMpKdeC63/rq7VDmlM7Xv3NMqmI61+4=; b=Z4Fg6JyALidb9BDEpm2zI+mPQqZKpLMmgjy9q65EGALJdUoH3ioreo+Jyv4PBEYCSq eEsQVXSyJnERwD/VGVCg40nILHJ0OuH+J7tQA7ob3G6yrWTTxukuLWbSUwll09qRWZXO vsaodID4/q82GWQvvXb2C1FJiv2bxRpBc4ZnLhhr73BVorp389tLER84m1TOeY5Ijuva hVfNVpazt1aPfsaQfNntUWaJ3twevviX0Gv8mA+NraLCy99P48/cwQ+wQhGOfvTft9dh aKETu8Lq86CtSc5k3l5ohSye1wLmiReYyeZQnCJzQH9UEUAv6rrpcEvcoxg24SiTIidA 1xJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712600812; x=1713205612; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hGV1LeAXva9vwMpKdeC63/rq7VDmlM7Xv3NMqmI61+4=; b=cB/i/V9X8HJhUOScmLhqq0OJ6vaFzF6Xkx/aKq14YhvtRYYfRsNmVOOuvV3MWTydrf IjMDj4nI0NtwCot10NXq4ki4lfbzU31lqes0/YKddh3m9vaYIzQi8rqwU7yMCu4YVsFK G23wA1/xUSPCdwCwFv6rZ8RyfQV0C/6LydKseq1n935KGqlMQhRnQEzsQnAXGJxLlZjV i+j04F/YKvjzLGk2xUT3RlbasY1kDdm/HaeuC3EyEC9qr9/lPTItdDOxXw+47JEwCftW aCxJ6SOACp+YpN9/VQGu8uAHaTHbj2XP3j5rw2fhpI+VZLQbJ9sS/Qxri18iai6lVlyZ glVA== X-Forwarded-Encrypted: i=1; AJvYcCWapWQXqTJsXsna0Maq/WkLvNDzePILDJ7jr0AMUjgQKi1FwbFTVVRh6vZ43XrCl21k7sl2SacGSmEQh5DO/18= X-Gm-Message-State: AOJu0YwzLeGUogzIrBc45FzcWDhwxJLF2WbqtGoUZC1UioH+OUj4NkAO WsPS8/Tit2V3DT5OJKCaV53ol9/dPejaEHzOHbI8XgEmPzEtq84O02nrLMcI7VFgkN2ij8Qzuhj Mag3PAhA9NO4yozyB5DRUie8rNh0= X-Google-Smtp-Source: AGHT+IGaIMTetURJ16gcV7BfrVPAj6ND92QU0UDSaM5JuCjKIl012b0XBGEQMls8nhEH2/0JlC588dZpJtK9QaFAThY= X-Received: by 2002:a17:90a:df92:b0:2a4:80c3:a858 with SMTP id p18-20020a17090adf9200b002a480c3a858mr7331659pjv.44.1712600812241; Mon, 08 Apr 2024 11:26:52 -0700 (PDT) MIME-Version: 1.0 References: <2d2f1e405361d2b36dd513e3fabd1fe0@gmail.com> <20240408181831.pizpq7n7k4n5u6dh@ws2202.lin.mbt.kalray.eu> In-Reply-To: <20240408181831.pizpq7n7k4n5u6dh@ws2202.lin.mbt.kalray.eu> From: Andrew Pinski Date: Mon, 8 Apr 2024 11:26:40 -0700 Message-ID: Subject: Re: [RFC] Linux system call builtins To: Paul Iannetta Cc: Matheus Afonso Martins Moreira , gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_BLACK,URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Apr 8, 2024 at 11:20=E2=80=AFAM Paul Iannetta via Gcc 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") =3D number; > register long rdi __asm__("rdi") =3D _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 > > > >