From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 601B73858D20 for ; Mon, 8 Apr 2024 11:59:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 601B73858D20 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 601B73858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::632 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712577553; cv=none; b=ibJ1rxphrzVUDT8pi/xbP4eqeZ0hHAc7nZufwsIy48BtD3+ZKtCsK+7j5MLBxBTDjzaVF0EGN1FDyXkdnfwpV5iWilqUSsZfK4o7zv+4Vo33lbxY+GNlVM46P3hcxrq63UeOdKSkRAsomGEmmXlxZdNcoMcUO8yHPksr8V8KoTc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712577553; c=relaxed/simple; bh=3NbOVYLhgELBCBEwoUD0QUVcFWcvs/i4HYTSyISj2OA=; h=DKIM-Signature:Date:Message-ID:From:To:Subject; b=SXOuOQN1Kj9NkZXSLG3x3IAZSVKR3VNnFmtpGFR3CmVKV/TbvZ+ksEmqp24pRaQfpVipMofjfvSaUrcgSNfGUntqtOybA67Bqkci7AuhxDaJ3voCTyqrmizYa9BzKSghvLlU3Rch5UDDsLakmMbu0DyEqBZP9HrxDFfzT7VT5W4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1e0bec01232so34667315ad.3 for ; Mon, 08 Apr 2024 04:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712577550; x=1713182350; darn=gcc.gnu.org; h=in-reply-to:subject:to:from:message-id:date:from:to:cc:subject:date :message-id:reply-to; bh=3NbOVYLhgELBCBEwoUD0QUVcFWcvs/i4HYTSyISj2OA=; b=WLlfLaA2Uvm1unOJWVu+JfwoInevnVrSPr0NuVW6hNTTYImwwjJ8YEY4zWFj/IdMbJ i2smIFf81jBFBFvyVrtk4tV+II3ABaS8pEUyHEms2sTMAlDNCOsHyzXlSgYlmNT6JQfe Dx3r6sMZ+h9h3R8ZMoqNP8NoQ/AlUJ7iq0Wc1JQFlNteweScuBVTYgoJn9VFG7OOFD0I CYqPS7dAUsZVoObbeIx8vStYkZntaHhQq9YZF2Ge95wkHnBc71z+COfcKLxQ1kkMZqe1 sQmJrB1GQz7xAtd8f3UV0Tk+Yior1vaMBd9rhqIyy1XxinCDIcmkEldf9IjE+bHUWDlN WCDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712577550; x=1713182350; h=in-reply-to:subject:to:from:message-id:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3NbOVYLhgELBCBEwoUD0QUVcFWcvs/i4HYTSyISj2OA=; b=NEdmCF8oyXW1wDLPajLNyHCeVWrlIII8ue6f5ySCgSOdxejoCI13c6IxI5yYmwG2dJ cnK+VPMDmMlIJPfOy53lMiXgK3uFzT3DW6gEbl4G/D/W/G8/ZB/HCqZnTdRCcfwlyGve 96JWrE7BtTeb0NyWfERpVW0Ch/E7N17gsc5qi9aZvtIsNYxCJ1PlpVomEIyUVYfKz1ov 1JR/Pvyk+/nS/K7gx60Z2xOiwPj4PPb8/DkvvxBsR0L6b82SaqwOiBBeV6tfDuwxPIZM OEavx/soFgLfjHi2BAaTpXdBzm41qM3zJI0b1pxOpoIB6O8UL7NNp+B7QY1pz24/n3Aj fsbg== X-Gm-Message-State: AOJu0Yz4A8z0N4mMxvb4p9YAgmpWo85QLr70J1fwwjup5Qzk0EZL5Xon 74Lmm3VtOBZcFQIbxsQUcCJ4vDekRoaE4q5y1O7SvAV7MNGA8opZEojU9E4X X-Google-Smtp-Source: AGHT+IH3AFyd6wEAkxJmZZaVIwNZDk/jzTCibnF5P9ANQx6lFTWzswFN7Oz6oDaVQV6e3eef2X1f2g== X-Received: by 2002:a17:903:2d1:b0:1e3:f012:568d with SMTP id s17-20020a17090302d100b001e3f012568dmr3964242plk.15.1712577550041; Mon, 08 Apr 2024 04:59:10 -0700 (PDT) Received: from localhost ([138.117.155.58]) by smtp.gmail.com with ESMTPSA id jy11-20020a17090342cb00b001e2bfd40b86sm6834801plb.47.2024.04.08.04.59.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Apr 2024 04:59:09 -0700 (PDT) Date: Mon, 08 Apr 2024 08:59:12 -0300 Message-ID: <2852e1ff0081b5fbc3db1c3f1b627e3e@gmail.com> From: Matheus Afonso Martins Moreira To: gcc@gcc.gnu.org Subject: Re: Re: [RFC] Linux system call builtins In-Reply-To: " 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: > What's the advantage of the _1, _2 etc. forms? Now that you mention it... I don't believe there are any. > The compiler knows how many arguments you're passing, > why can't there just be one built-in handling all cases? You're right about that. When I started working on this I just mirrored the existing APIs which consist of one function for each possible arity. I have always wanted a variadic system call function though so when I saw that GCC had variadic builtins I threw one in. A builtin doesn't have the overhead of variadic C functions though. The compiler should be able to generate optimal code depending on how many arguments it's called with. It's the best possible interface and strictly superior to anything libraries can offer. Would other languages supported by GCC benefit from the other forms? Perhaps variadic builtins are incompatible with them for some reason? I can't think of any reason to keep the numbered forms otherwise. > Your proposal doesn't seem to actually address the problem. > If using the clone syscall causes problems for glibc by not > giving glibc a chance to set up TLS etc for the new thread, > how does making it easier to use the clone syscall help? I think that problem can never be fully addressed, only worked around. It seems to be inherent to how standard C libraries are implemented. The C standards apparently make it impossible to avoid either global or thread local state. Locales come to mind... Compiler support for system calls help by eliminating the need for the system call stub functions traditionally provided by these C libraries. There's no need to link against the C libraries just for that anymore and there's also no need to implement it ourselves since the compiler provides it. The result is it makes it easier to develop freestanding software targeting Linux.