From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout41.security-mail.net (smtpout41.security-mail.net [85.31.212.41]) by sourceware.org (Postfix) with ESMTPS id E80333858D28 for ; Mon, 8 Apr 2024 18:18:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E80333858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=kalrayinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kalrayinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E80333858D28 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=85.31.212.41 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712600318; cv=fail; b=dbUrAyw5g+S5RNVdnSohYwoXg8WZ9Yik4qYTuVA+MVAvO5TghoFtzxQWgoL2M5HkbYeuP/4yevQGReE7hV4PPtiqfAc49vrdVpFEJk6MoKdCLyYBV+P6nUQ9gy5XYn4qSRk8sRRSaZ4pGjVy1Wdu2LN4bD9u6ksfmyclzctU5Ds= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712600318; c=relaxed/simple; bh=tzHHiiTjGlFOD3WXobPqOt26Ss6SvpvUCOU1EEQTGts=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=aVXV8Z9I5A2E6tsKW8fW8RjI/jt2TNvXfG+NJ4C1neI861JOy9nm4N/Wn+oMY0AGf6lNCN1z7H7Cz9lqbEdknN5+Ya5RpLrL+V+EfCZ6571KXARMd+iYk1RSpuNqWy8aejU8shzxhvRkfQbtUQewMT+gTrXjbd3RwvuWLZN2KUM= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by fx304.security-mail.net (Postfix) with ESMTP id 885E1154FCE for ; Mon, 08 Apr 2024 20:18:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kalrayinc.com; s=sec-sig-email; t=1712600314; bh=tzHHiiTjGlFOD3WXobPqOt26Ss6SvpvUCOU1EEQTGts=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KREKeMCXTFSxTPvYBbAZb8DIKUWtC6MFWrSSL8iAz1KHHMMizf4knrnVRBv5llUnR YyAJ5GtXkfmmV2Sx3PyesrEGMhIJiSWuC8IPssP3IoBwKIjaFpU+bc3cDcuxs/9fS6 o2Sh9qbD8a/BN/akVsriSyGbqCsUhpKuagrrJHmw= Received: from fx304 (localhost [127.0.0.1]) by fx304.security-mail.net (Postfix) with ESMTP id 6A0D3155B85; Mon, 08 Apr 2024 20:18:34 +0200 (CEST) Received: from PAUP264CU001.outbound.protection.outlook.com (mail-francecentralazlp17011006.outbound.protection.outlook.com [40.93.76.6]) by fx304.security-mail.net (Postfix) with ESMTPS id E445D1555E6; Mon, 08 Apr 2024 20:18:33 +0200 (CEST) Received: from MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:33::22) by PAZP264MB2701.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1e6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.55; Mon, 8 Apr 2024 18:18:32 +0000 Received: from MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM ([fe80::840:d8f3:5fa3:8ace]) by MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM ([fe80::840:d8f3:5fa3:8ace%4]) with mapi id 15.20.7409.053; Mon, 8 Apr 2024 18:18:32 +0000 X-Virus-Scanned: E-securemail Secumail-id: ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=frTTo5R/UrXMmnWZ5iXzYm5F6IbHmgLsKICW5y6JsrDfN6KFq0J4/ZdFgFecqzER4uK8Gp2uDNhV//uH420McX67kUxNBj0WJRxoaRC3c6PtPn3aicEG68YUagd0h5xuf+I0HsV6bQrWTalQxvbS9XRj6rLlgBwQKfO/sdjN91dNoeDOAKLxsv+xg0TyFOEN5LHv3+buoqG+0jeWu2Dxqcyj+LqlE9RbhVBr66x2ORT4ZDBF5EhvGoMam0pBD7HPNCojrVZCOSFXj3+FJ+ySZvdGjagSaUgoWSJIMvZyoNv5aVsO3gA/wLjhGl53hEhVo4lcgNf43YzCTzQHvxbfGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2kHdGZHSpxIQdOsiJklIbEZ2Uf+NNu5ji9UvJpAUxho=; b=UhLkxMOoWQBeX/OJCeUnYyL1vC5LCVzOsUyFgBAsjPA9JVIAKILXFAdKOYrmttHLdk57Y9jUVRTJcwx0Enw6E2gKA+8R6pqzlJ8R8q06Wr9gAPtRn6kHn8vxJtWoH9Pw4sE5uZepDc29joEuCuuEYSBDzTZz8G2ovBr+yMXDLdQS9ZnoaSd1bY5AmXC3wwJLXEZ7VgdoYhAxb8KMEVjT+1Hi3/5lhgZsmpvWPdKrocuEuWAVC/g/VnTjNC8ASHb+8IbYDBCNSynDADk/XyNmRYDuWaeKZuww5cphp+HNq0UUH4hpqFvGq6PiTqFA+xvY5dP8e6orNt+bwyCP6pi8pw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kalrayinc.com; dmarc=pass action=none header.from=kalrayinc.com; dkim=pass header.d=kalrayinc.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kalrayinc.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2kHdGZHSpxIQdOsiJklIbEZ2Uf+NNu5ji9UvJpAUxho=; b=ChilPD8M5Vc/ljGXtvhqmmKSvdbOB3cyjBeaDQdAPtx80VES2+XKTQw2FRp+ZK3cJNDPKJPLdGx3e0OK0EswoYe0RdfZm7W0sMI3RdtO58i9Y7G/tvcySQ+a/aDlJcYKnng6uaQaovRuAgftMp2pRZGEeKMIr4sKIzfsFevbtuZSXOcm3FgdPjwFsiGs8Zszo3UBgp9ifxWCQNXS+Nd6bfVSgMh/7Xqc7zwIODIYp1d8rqNPrru/ZopdFLZYOK4s1L4BApTLQ96y+cqPR/HqEwIXarOxSSrkWQ96NY0AXlQa57S6RK1oezczdO5a4kWNd8o+ICaDWUjW3BZdnzZT3A== Date: Mon, 8 Apr 2024 20:18:31 +0200 From: Paul Iannetta To: Matheus Afonso Martins Moreira Cc: gcc@gcc.gnu.org Subject: Re: [RFC] Linux system call builtins Message-ID: <20240408181831.pizpq7n7k4n5u6dh@ws2202.lin.mbt.kalray.eu> References: <2d2f1e405361d2b36dd513e3fabd1fe0@gmail.com> Content-Disposition: inline In-Reply-To: <2d2f1e405361d2b36dd513e3fabd1fe0@gmail.com> User-Agent: NeoMutt/20171215 X-ClientProxiedBy: PA7P264CA0234.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:372::15) To MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:33::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MR1P264MB2482:EE_|PAZP264MB2701:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /SBkCxj0MSfuup7L9IPKMff5E+95nq/jgVHC01PmQCfMSly0b7Z+ez2EaWMHmdub4zJqy6AGES0nUT4VL0erXLIUTjnX3xbPmT4qoe8u/QDa58uGVUb/FlT6Odzp1wSOy21dTHVKKKoXAKoGWmOnnv+PRCEkbyThdMG9f0Bo7h2oyeaePkuPmVSTza/DMqvuO34Iu4CABrWN8MIvfQcTD5ByJ4qd7dOiX03ssA3oKp3IavU8bQa6XtVesNVI42HpowmVTlktyRIc7VyHln5v8utJGsAJnH0GqdGHncPaaUDVtmZp91z6J3fr8fOzUtYUpPIl7OxeaHBuhmDKQmVxNbFaQ+BfsWVR1O36jrUczQRLvV2kozfpjIlKc1G7jBUV6+6iHB6H9BdtbFseVKJTBR1RMAiC+oygk4UzqxOZsXQPujpSbqKkbijavZO/Ry0Q7fxe76TYvCrV5LfJmItRqLz+MO0esGNG2d09L5uxuccLGFqJcYwUEk2iwreKvrPZUe3XtYJXdhwdYxQwT/IWIkx0EMHXDcfMys1Ul2WcttATr58NOE9lXk0fSl47lCA2WWBcHSDTWzylHjrGCzzsa7emRPDtEXioBlE3KcbyJ/s= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: t+i5vhMFYU96uUJs8UcILg7rvK50jBelCDlRlWgp7oD7UymhNojR7mudXlXhLGEv9eJCVDiq4yvIxa3m2vy3aSuxPaQHcMO9YqUxzqrLokng3ktECCbwIiEcArJd96r3Nq2lYaelivGP6vwXchY4/ZGwQnRYASVxv60q5nBnI/X5EaPwI9/eZ5kcmuQeKLkBheDM8Z+c6QeBnAs9E3aH/A++itgg4WZD4o7RsSAEOPZ7LTqKAKd7lAn6oi6PTXicPB8SzTQZAvcy853nIxn0TL0W++pWoRkQcWWz6bh/lFTp/YJW3n9SPvrt5DTmfY1SK3Ujai1Pba5hxWEwbxkJmrYZbAP9OqK3W2YUPNEP73Rna2+MFLci8Ik5zD+wuCL/8lLwLaHxxS6wAdP4hAxc/LlU+gZg0F9NaqcNVV7aTX2VW7Ce5l/YEeg7zKF7+3J2S4t7m6V/sprMK9AgNk0b/shU3qMkegJY6Rm5CLQxmg47zBKRA57VbTxq4MZog+2AkG6YLcKYue2NI8STdwP/QXdOo9zv2aeEZ8zniRHJBMpGn3ffkNtZyRuPgm8jJvpDcihaUxHSarvxgQ6CGzO3UQeZ13o3VQMHstaAXdHMQqH8wUTjIJ0v5DPB8I58xZi3qhtL7lm5R8wCix01EBV9A4QB28bi61WVP5fS1uZrfJqFVpDCBFqbKC8x5358naVTuXOTXuc/nDPbtdzr+qxMYpuK+VPdyNCjwx2ve6ZxSaXkoVPaLvDj8RDS3G5hl+lVEXjS80utexe7dEhGrBq7zAkOBG6qtZZNeA++BpDP3GTL8BEWxGQuiveg/50k1RINkOREyoLMbz5ep+nHHkW/hhVR6UzT8Jv42BPBPgkh0TI9pr7AsvawgRlktuE2wyEfRnW9ECulz7oHcqrBTZPr6/9rIFbk/7FzLffekBmRyuNRCoQ36jCHrqY+pOMx3ck5 ZCQP1el6IXvYpYFsWQzEse0H5vzXA1G97Aca3hwMMYqlYLdgUb0dOYckK0PyNup9usnxWytjuoZ17hd1bo8k3X5TbgzhKfxZV/vDLsN3Q6lt25jOmbNQEFxDTR0VyvK+87HfWFsTEFkqXIo08Hwv6GvQ1DFGFGjRi9iBPxB/D2lpUndw/Kkp2PxNnGpKobEes4+I2dMKLskJr5Pgd73w12gRRMnA42HvREKKAYYkZv+D7DZvDnqSx6zVeA1qS6OYseJT0bq4KwzSu7uHOQyc7wauAoqTqdItBFIYhhQ5lHOQeLzoS/TrKrdy4SkFO7uzq2fbyHgED/fZcCS/hdYtSC9ukFnIc4v0EEc5MKzlZNdpC4M4ZAgccO4TEP+Yj7JRq+lNGmxWmumoxn+J1IBs9I8gwi8ZOwB/ET+4659FOUZcCZ0M1/joeeayjBJdhXe0YDqcyNwC4CXLNuEwTuHkRlfWHZPb3NVVPWN+jdHSXES+A77ECRSMb7II/p3CNlXTmBnKv9gXpcWX0CczgM5quw3wcPQqjtY5nHVcXqiTJHOZideNU812pr2T1jT+5DH5uM0WQdFXswRjzQJhcn50AZrpBZYtiAxPma9wRt987M/sz1PzUZ22xD4dJrXfFoJD7ymsfudfvF3GdFHCu5Q8gQ== X-OriginatorOrg: kalrayinc.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2adaca58-69c8-4da9-4abb-08dc57f84c61 X-MS-Exchange-CrossTenant-AuthSource: MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2024 18:18:32.6576 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8931925d-7620-4a64-b7fe-20afd86363d3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: oQukBUXcn4TIAIOgbggzygW7tiknm89hLv2AzBRw6mT49276kjiQ2LlLaYtRNfNnmO/hlrhIIpQe2nzpYyswcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAZP264MB2701 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ALTERMIMEV2_out: done X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: 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