From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 870803858424 for ; Mon, 8 Apr 2024 13:37:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 870803858424 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 870803858424 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::434 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712583452; cv=none; b=UKfH5mkDadEJ1v2towIJeMsZO/LLaz1K54wb8X4gOrA3NvtUfbBBUEsrv5pL39qJMH6Wq0qVQoacJi2ZMwXeNpcRJhKU+LnFd3p8Z9WgTwVkNFvYF1TaEex5BV5o16Rsr/2xHY7lPqqd9R98RPn2TitHvlM04PKxYDBU8p9T34E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712583452; c=relaxed/simple; bh=u69K3XrUjzeUFWo12PAD5/a6zN4ANvdsbL8hXfQ3ir4=; h=DKIM-Signature:Date:Message-ID:From:To:Subject; b=JGX14tl5TTKpiDbG494QOaA+x4vPkWgCrKieNwKYKUx6SImsAnYn4Q3qxoxuamQ2VvuOsChppT+/GrnX6uc6PBcfYo2YmxEf48kKAynkDhj7eYtjWS+8WUgqHfovvu9choRUyT+ujPxVEN4CdeNwvnQr623pJ+4Veub1sPCpA7A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-6ecf05fd12fso3647208b3a.2 for ; Mon, 08 Apr 2024 06:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712583446; x=1713188246; darn=gcc.gnu.org; h=in-reply-to:subject:to:from:message-id:date:from:to:cc:subject:date :message-id:reply-to; bh=u69K3XrUjzeUFWo12PAD5/a6zN4ANvdsbL8hXfQ3ir4=; b=go96FoP/91K0Muj85Urmu2THjWgibOxoL5RdDsO8IjuRSFs+gKCPx9/87OIk669cSz vcGpsEezUv0HcBvD94W+tpHyL7ANYhfVVQyNzU2L4zy9mhwrolBXaKFahxFPoO/eH4LC eawP/xKqNJ7Mw1aTsgFHeMKOBgay4whv+TV1keZL9WXcAiX7p86u0f5vnNBk+Mn94yZu N4+QFMcj1n7KNx2ab+wd46MFHx4fi0nfJHg+43qkT+iAJhNFFSnXe6E8NHZVKCH0vMji SJg6w6Dm5V1mCEeIRVxUiWWjfMgBVtf5k5CSp+Rm9WGVdG9jyX7TyGk6XvN6+zWBrZ+i ZkmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712583446; x=1713188246; h=in-reply-to:subject:to:from:message-id:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=u69K3XrUjzeUFWo12PAD5/a6zN4ANvdsbL8hXfQ3ir4=; b=JExL1AOs1PllufpZK7K5K5oFFMH3jcqviOsEJxRzNXT1EBO3xDIQtaQ1du7p0XOYsV nou63k/CdWQhdGyC5Ezf9iLYaDPb+eAXDRLvqW/kDWqubzv1ZbKD15X5QaETA98D1NuQ 8MXIiA+4YXubFuaK07u+uuZ1tg3h9f8OyZLuEy13eY1dHGjDUP9In13WlPSmHuGNXk8K ks9DqDR1UxIgqQRDa8VbhYk7I/fWWRfSWnHTCfNutSZri0UlUMUSpWNTvIg6cvxeveJZ fFfm2B4UhNHB2YTC2HlnLKpOK7f7W4pTrVWmdjBLfP7EkzdiqKoOkdZv7L7ghASO9ZQT xiLA== X-Gm-Message-State: AOJu0YwIQ/8SPcqHYf+CXrgTZ7lIPKGI0bfsRXPE/HG3cvzrQyyh/HcJ 7Yl7mQTRsVGr6a5EQrKSZhTKW+vHaBLrzcjrWAZePnUC5EsuTpa4Z/7xwuTp X-Google-Smtp-Source: AGHT+IEkhEKVpk1kxcUSAPFlapihbya+U5Ug2uYUnsb9e/WL9Qwe9+78Rp3QWplqojHUZxn69HzOng== X-Received: by 2002:a05:6a00:2387:b0:6ec:da71:9c4c with SMTP id f7-20020a056a00238700b006ecda719c4cmr11349472pfc.34.1712583446149; Mon, 08 Apr 2024 06:37:26 -0700 (PDT) Received: from localhost ([138.117.155.58]) by smtp.gmail.com with ESMTPSA id w24-20020aa78598000000b006e65d66bb3csm6555156pfn.21.2024.04.08.06.37.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Apr 2024 06:37:25 -0700 (PDT) Date: Mon, 08 Apr 2024 10:37:27 -0300 Message-ID: <1742c098fd77d159c0834838ee71f283@gmail.com> From: Matheus Afonso Martins Moreira To: gcc@gcc.gnu.org Subject: Re: Re: [RFC] Linux system call builtins In-Reply-To: <87plv0w10k.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-1.4 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 autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > There is quite a bit of variance in how the kernel is entered. I assume you mean the vDSO. It is also documented and stable. https://www.kernel.org/doc/html/latest/admin-guide/abi-stable.html#vdso > Unless otherwise noted, the set of symbols with any given version > and the ABI of those symbols is considered stable. > It may vary across architectures, though. > As of this writing, this ABI documentation as been confirmed > for x86_64. The maintainers of the other vDSO-using architectures > should confirm that it is correct for their architecture. It is an also entirely optional. The architecture specific system call entry point is always available. The vDSO exists to provide much more efficient ways to access frequently queried system information such as the current time. While the optimized approaches are preferable, the slower system call entry points are still available and stable. > On x86-64, one once popular mechanism > is longer present in widely-used kernels. Please elaborate. Do you mean the vDSO? Linux places a pointer to the vDSO in the auxiliary vector, and a pointer to that vector is located immediately after the program's environment. The program will have to walk that vector in order to find the vDSO. If the vDSO is missing, then the program will fail to find that pointer and hopefully fall back to traditional system call entry points. Perhaps GCC could also have builtins for accessing things like argc, argv, envp and auxvec. They are part of the ABI too. This would allow programs to access the vDSO via the auxvec. It'd also allow implementation of ELF entry points entirely in C. > But using a builtin obfuscates that relationship. > There is no __builtin_call_ms_abi, is there? That's true but that's because there's no need for those builtins. Functions which conform to specific ABIs will have been marked with the relevant attribute so GCC will know how what to do when it is called. Linux system calls do not actually exist as functions so they can't be marked that way. It could be implemented that way by having a naked system call function whose entire body is just the syscall instruction. Then it could be marked with a linux_syscall_abi attribute and the compiler would know to where to put the arguments and from where to obtain the return value. That just replicates what the builtin is supposed to do though. The builtin would not need any declarations or attributes. It would just work.