From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 694A3385841E for ; Tue, 10 Jan 2023 13:21:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 694A3385841E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lf1-x135.google.com with SMTP id m6so18353024lfj.11 for ; Tue, 10 Jan 2023 05:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/7DX4cR7GkSUNX63YNydNm6Ja2cyOA44pZfMjHXejtQ=; b=Xbwxwe/QU5YGbWLA+WKhKVBa5Bq/wjuODipMTxshUbBhQT4RBVDn38Xmu2+8Z91iw+ qEspOp1tnnjB223+CGcElMkxZSKs1fGE1fSXv/MI1EuV3REDVN08FInxGwxWfLcNhHI4 eviRBEq6T2TyaJD/qpxKtGgu5QqJGLwnqWFBLb5NomCqSllyWPXlZ0nUc23Pmktq+GeO gzy8Y+E0WkOnROyXHidusYm+YB6O4X8w0mwtl0HS1apLwzI7SfhFCieIcksRMPqiixKX FlQtrOxAWZDE599r+DfYdJe9nFa625ctj1LURBwGTz+5MMz1dLCFFPbPbJZR+ejtuVRL 76kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=/7DX4cR7GkSUNX63YNydNm6Ja2cyOA44pZfMjHXejtQ=; b=U6DMueUVeHuPptN7oCZ9Ch6KbgWTDzI0WlHIQFmbnF+GXTtwSpV8JRHX4iwDGoeUGB A7+D0bIa9lp/3bLSz4mhZY+4jKoaHPeTB5Y44p0xvO1L2+xKV1ZeG2KmSZHSi8yDZcKm 5mYNGKYAmmxll7OErHEJTagcCbxt2Fu7ckuwcyin1/13VHrGQ073qbVx7rirpzNgZ8Oe kjKd1o3d9gMP9mhTvhpZ98sA/nvhZZlqRZwo2PXWTjhScemId6vZO5nGwq5J7jyOUrdQ Y6jSoa0gEW3ifGgXTUZVLbnpbD+3R0fw6HBDJzR3iy43FHhcZUsXGpeCyNBZT8r8qp6m +Ttg== X-Gm-Message-State: AFqh2kp7u70O11mIqKW3poLMYJJ8gsSaKp4UwBdk9iHx6wgw5ig0Iuao tQS0Rkz+9BoGc17Bf2I/Ih2KYph+SVV/Qa43FqBvcg== X-Google-Smtp-Source: AMrXdXv5UFhRRgFnetOXg7pX7CBVg65T/r3IRZiF6DosVeMDqZrLw9C2LKGn7xNXyEEMh574sKl8CDn29vi4cZM4l6g= X-Received: by 2002:a05:6512:e97:b0:4b5:79c9:bf85 with SMTP id bi23-20020a0565120e9700b004b579c9bf85mr2822548lfb.541.1673356875751; Tue, 10 Jan 2023 05:21:15 -0800 (PST) MIME-Version: 1.0 References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> <73c0124c-4794-6e40-460c-b26df407f322@rivosinc.com> <50c598a6-e3b3-3062-abe7-23a406067533@rivosinc.com> <7430f494-9b43-5e03-c1e9-6b83e2611a11@rivosinc.com> <91ef3c45-165f-d2b3-7c77-322c01802c41@rivosinc.com> <18465ca3-934f-5b3e-170c-1ff0edea3a89@rivosinc.com> <1f8f1d21-4a19-54fe-8b29-bf9e2a8501d7@rivosinc.com> <3a838afe-974b-60bb-a0e5-83e366ec652e@rivosinc.com> In-Reply-To: <3a838afe-974b-60bb-a0e5-83e366ec652e@rivosinc.com> From: Kito Cheng Date: Tue, 10 Jan 2023 21:21:04 +0800 Message-ID: Subject: Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break To: Vineet Gupta Cc: Philipp Tomsich , Andy Chiu , Richard Henderson , Vincent Chen , Florian Weimer , Rich Felker , Andrew Waterman , Palmer Dabbelt , =?UTF-8?Q?Christoph_M=C3=BCllner?= , davidlt@rivosinc.com, Arnd Bergmann , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Szabolcs Nagy , Greentime Hu , Aaron Durbin , Andrew de los Reyes , linux-riscv , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: Hi Vineet: > But you are not suggesting that there is a scenario with executable > built somehow with V instructions (even .byte encoded) but not have that > info encoded in RV_ATTR_TAG_arch string. And I'd argue that it is user > error, they need to make sure that -march had 'v' passed to compiler > and/or assembler. The concept of Tag_RISCV_arch attribute is minimal execution environment requirement of the executable or shared libraries; use glibc as an example, we can compile glibc with rv64gc only and then it can contain vector optimized routines like memcpy and memcpy, and those function are resolved by ifunc, which means only use those routines when vector extension are available, so the Tag_RISCV_arch for the glibc is rv64gc, not rv64gcv since V is not minimal execution environment requirement. My expectation is most distro will still distribute with rv64gc for a while and then optimize function with vector extension for some libraries, and those vector code will guarded with some runtime check mechanism maybe IFUNC, so Tag_RISCV_arch for those libraries won't contain V. It's not clear in psABI spec, but intend to fix in future: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/292