From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout148.security-mail.net (smtpout148.security-mail.net [85.31.212.148]) by sourceware.org (Postfix) with ESMTPS id 117123858D28 for ; Mon, 8 Apr 2024 20:01:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 117123858D28 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 117123858D28 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=85.31.212.148 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712606506; cv=fail; b=wPOmCJ0G7IGcjQmAN/FnaxCXmFVmlw3p4H2ECbLIfLtEDZqKyQpq4g7uJG4zT/MFinGnF+PKp4onua+N1+fmaVIpQzGDlTl+jIGD/h70hHNlLwqb5+h4OSnu4p5dkoKzcfxxPaIqp/AUmefgQlOoIKoJZExjmJgMznwA6uM+i2c= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712606506; c=relaxed/simple; bh=vrTFyvNm757oKInPcTr5vFVDOKugPZvXzTKVBlqSaG8=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=QZ0hZIqZGGK4knzgpUQxFiMqq9vbWHU7Xp98VucWRB5sMH04mlsJsfikpx//p+WXVq80uw/z91PdXFHSUTyudE4X7aWTR8bcnRl67cT1abaebFmZNGKT9MttfHZ31wSizJ/IgA4slxpXC0xxBmiQDN8jmAQZ7RpufI1OrFODvrQ= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from localhost (fx408.security-mail.net [127.0.0.1]) by fx408.security-mail.net (Postfix) with ESMTP id 17558322A98 for ; Mon, 08 Apr 2024 22:01:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kalrayinc.com; s=sec-sig-email; t=1712606503; bh=vrTFyvNm757oKInPcTr5vFVDOKugPZvXzTKVBlqSaG8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UQOMjobz4wpNjcWZYLCBoA9YN/580/UcH80Qqmnfce1ov8yajAJ1K3QsxvtrNZ/lC OFH90gRJEjSgjUEi7rdF1S4z2KAFTGOh0WCZGZCMqrf+6QhMyf5nnMm/u+0QUKfPuc CpIWCIPbiHDofozofz+PXQ9MP+54exY+7rEZBACs= Received: from fx408 (fx408.security-mail.net [127.0.0.1]) by fx408.security-mail.net (Postfix) with ESMTP id EA609322A8B; Mon, 08 Apr 2024 22:01:42 +0200 (CEST) Received: from PA5P264CU001.outbound.protection.outlook.com (mail-francecentralazlp17010003.outbound.protection.outlook.com [40.93.76.3]) by fx408.security-mail.net (Postfix) with ESMTPS id 78E83322AA8; Mon, 08 Apr 2024 22:01:42 +0200 (CEST) Received: from MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:33::22) by PAYP264MB3470.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:124::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.46; Mon, 8 Apr 2024 20:01:41 +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 20:01:41 +0000 X-Virus-Scanned: E-securemail Secumail-id: <2aa6.66144d26.778ad.0> ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lx7AxCXowQyLnM2wmgjvZLhTgwj8S3Bg8hNG0i8RsApEgoamUtFi8Mgudf9LhxaZyncJq2GK9dX9tvo2EfAdfAr2uAVxAKvS/2hacGd6hVIScslzdIn8AB+ucbr3xkd0dUhWCOAqWYSwEV9JdC2fOWwdUF/jYYYhXfEdArm++/cd850GYEVmnh2Rwx4oyR85KNP1i4W7pkc+pg4Y9+V9HgEvOZdGS3PHEuClLfwK4tfoLtug7WyShMuEmQPipQJ1b1urq2Se/JXNo7tRcx6IP0QOh+EeLjR8FaRsHvx5AUpkx+Fe+0CNRGZpVukct2cP3Y0gl5SwdWlrfLJAJ76EZw== 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=TUVqJkUZdCbr3ubjOp0t09dOqjOTINq7InobtF0WZz0=; b=Nx+JbWESJhPVhkPiMiBU2HCw4wKAClBSMHY+n0ZEccKVcu17+DE6PegFnoZb4+RrSngju+rieDOd75+2nGu3k1tQT1QVD7/NckiyegQkACKSExnaq99pGeYelOw/Jk5phrIyVY3FyCv5CY4H0JOjBS6rGZIznsumGgcyPsxpxORvIg8Sgb1Kz5bUKgsGqfUROgbVGD8svpvm4cKMlEEoCMAjElVotCIZUPbhxTiUENO2dWthAWNYBQmEsj+rsrVuOFMkbHyiyooZf+PKv7ed+RQWrvQ3XjAz44qF02S2S2RGEX9XBxhq/EfvFWABjf8TNS4lELX/DXig8BFE3oGTkg== 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=TUVqJkUZdCbr3ubjOp0t09dOqjOTINq7InobtF0WZz0=; b=uxelJpYJFwdg6CE21ma8dR09hr8BTjWuMUaBbM10edhBMx0P6SwOW8AEcZBkHMDRCmrz0Vk54EupC1QleZZJWeLftr7uoydW8IgCDd9eHAhau2X+nQVP1/HeJcMpg0qJKSQC9B3Zc4MsTPBjuE5HFBRCL1xX6LlFrg/YvdU9F3+hX45tiYAKeC/hePb3IChaRB9h7yRPVQQW116+eKIBOY8zo5eqFLr6qZ+eBtjMOzmhEy2XW4Q0kAGJq0IfsYNZ2pujVDqpVVUo9bfU69urp3M/BmM+xo0oUC9lRR6MZA9XjZMNE/wDefUYTjG4EPd4QiD8B4En3vKvqGde96iNHA== Date: Mon, 8 Apr 2024 22:01:38 +0200 From: Paul Iannetta To: Andrew Pinski Cc: Matheus Afonso Martins Moreira , gcc@gcc.gnu.org Subject: Re: [RFC] Linux system call builtins Message-ID: <20240408200138.kbl6n5te2joj3csn@ws2202.lin.mbt.kalray.eu> References: <2d2f1e405361d2b36dd513e3fabd1fe0@gmail.com> <20240408181831.pizpq7n7k4n5u6dh@ws2202.lin.mbt.kalray.eu> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 X-ClientProxiedBy: AS4P189CA0012.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:5d7::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_|PAYP264MB3470:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: F2L42Uo5YzQwpFPt/uCOq+XGXP0ofha0PKJMIyqmttj5Gyx1OqxywkNMwOWBbJByqG7d+3G8wZ48F/aZDhCu6WDqA5w8IB05H69tCNlJdaa9XfCe1r3TxagTvQua2FGGuaQfdTUr25qr3FoHawiq+nmlHRFBZogdTd1/a8xBXhp7DUcp0d113leKIjjIJoVJBSoCY1DHMW6NilZ2ne1BXmKxi27HzW4llaBPa1VGAaz2KIOpLLWQ5ippBEY1zcd+sxRk8Zc8rCU4OoT8N04j/+4EFKXEmgy5bKnRzrLyQxvM9pfUTmUimgsVq55ClWl4eJxRmperqunnDw8acocu98wml5Fm1LIeG8UnbZaa6Y/QeEQtqJYq2PPN9vEgwvzfvpO26epGolth1Cno6AJzr9xbgTL/iU2irCfn66K7ejJSlNUo2B0efsVE6Olk8SzLZRH8Zv48qJzCFnV8YTJBVFh2+mBmGSZw7nHka8166K1o2JnaP6IQvLLkW3qM7tieGEcI7hg4MOaiYUhf9OuMRd/Ry/zZ1+PyRrnbrPem9XOkEBsCBCHlLdUhuVi9zGzsNqcXttosEy8VwBKqqPL4m9aEm917IYirHyh9PGUHgmo= 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)(1800799015)(376005)(366007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: /OlDw/Oi8bKQ9iDtuind9VVdrhqeitozVvgKYBjrWezFDWtAySN34CxoisLn2Ccebw9gvxObTs1bhcUoQ/z5hJzoDa9mrFAPu/3wpzS46TxYej+PKHRrxIz0uKknnF6r8o714i7qX6OYyIzsQTTR1/uXe0tXXKecz6lcaoPQOTJSkVXPSesfrXF2cH0pEvTM6jhyxVsnhbWtlaIo0nSCBN2JzTO6YzTuMDLzOfiJl6pVpwCzKg/flb7mKzLYKBOUJiGgRof+QJoY5jDENm3m/eW0hUWujKd1a7bjqwVFLsQehXqIec3+kDf7e8EgIr1Dx23HH06ApauK2gGoRCFrPjDWkwrg7wYZBEDZU9mkoxgYqn8RJDb4tZFwcuQCZC8QUjGXSjCHx3SYFowQ9EGxfNkb8r9aTXI3uOJ4P9SwOeVnBLl2jSuaOw6Y8f8zAgzB/uY4vUz5OTbE0pJVQPU14t2Nh4yB/RKQ0vTXWTbsWsA84cpC32AMb9XVL8jS8MoL+WGcAsbBe8TyIYLi/99Fzx9pJjAI4MoZWLst/5j6pd2wWJoHTHMI+RBan0G6A/TRz3vHYztvTTsKWNSpxu1hQ/yIR30mV5dk8MettIKzSE9oanp+xVN5sZ2CeH1b6I5nXA/qk6OIlZPwe4jGsL5cg/VMStPCqcLMY2aOGG78mTfTTWnwAqxXnKQjrqNRN2TO6fgz3rftMnmDXnaIpdEBdsK6Cu1ys0QkvmvBDhNsDtwDs1DD4bmlJdOjN/WvyZaSHCMsdBeis9OvRCpz1sEQ0X9WoiUV4VGEPtp3yhjDev6HYu5UBpCRGwUgMrnKsOgQL8CkclPd5+MoPF84iWMpsZHXJN8ewkv3lytuWc8IxD7fWfnW06QtALlK+EMhR68DACjtyef+IAQFQ9hB0y5d2YSUYl8xk/Wj2zBcWCPYLdj8NDv7LsTnwIIA3m0IT2a9 mG+aT2AOqx7d8xmMtbOCsqXoWqCM+pdzjO45A0zRmP98oQX9A24DHof1B0f+84/dakxE921z7NnYj2v2QK/729nIWz9N9ODHP3in2v5xpIs94juKX9K8AsF163NuHdwZcHP6OPcv23/K1vsPPB+0vWRfPJT+l0iVY8Tnjgk1pjbRe4NjQTWC6T42kv8VA31MEwt968K6uGYPwhWfuVA+ihVmAN7yZPdBtt7PgFQEjhItiRBZIbPd2lOblrBe4aXhWmHscXm1C5gnI0AWTmB9+mCCjpp1J4wrtQ/Xn9Z1Ysvl/j2UAKE7Hhj/zOjvJl6kYz/VLYjExzm6WrFEoLjs70OQCl2EU6kqbQqxkaD/hHD7kfyPZPlF4RxRfiwHoA4MxZsDOZHHgco+6D/EZ/Og2McEmGOKuX4z+zlsVGRaQ5Y5QWov/QRCBqhN98sL/jHbBszLxqbKbbco5H+jZLpgOEPI6bmvmxpWUzgZwcDpZ5Kh9fhHd8x6MjfmHQL1pIZ8ZmVi52oe4M94aGzjYR+g0gp4Om924PKg92K/izpeGnCAbY8MDMd3QepVWK+sUAdi027Ldd6r/ZisiwlFAtq/KMcWka5OGN9WYur4WkFozFk80JQOCzrUwP4TKzWXetQhXhzlzuLB1qCg/L7AQ3Q+Vg== X-OriginatorOrg: kalrayinc.com X-MS-Exchange-CrossTenant-Network-Message-Id: 324d9f07-6df6-4e6a-8ee3-08dc5806b4e6 X-MS-Exchange-CrossTenant-AuthSource: MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2024 20:01:40.9282 (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: W0X6Tr7qW9BorRT+b2dsWUrI3RhCgy/9AfBKThmfQPLPPbMveHF4XxUXFRPf9jpZVXbE2UUk3fkivNG1pOzXog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAYP264MB3470 X-ALTERMIMEV2_out: done X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,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 08, 2024 at 11:26:40AM -0700, Andrew Pinski wrote: > On Mon, Apr 8, 2024 at 11:20 AM 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. I fully agree here. I was mentioning the macro solution in the case where it is supported outside the compiler. > 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. > Another case would be targets allowing an immediate argument for their syscall instruction. Sign extend is probably always an error, zero extend may give the expected results. Emitting an error or a warning seems a very good idea if the size does not match. Syscalls can receive both values or pointers (which may not have the same size as regular values) which may complicate the handling and the types of the arguments. However, for most complex ABIs, all the cases you mentioned should be addressed by each target backend by specializing the call/call_value SPNs in their machine description files, and specifying the right constraints. > > 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 > > > > > > > > > > > >