From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kRcPId0rDmnlyykAWB0awg (envelope-from ) for ; Fri, 07 Nov 2025 12:26:53 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=syntacore.com header.i=@syntacore.com header.a=rsa-sha256 header.s=m header.b=VgOwowYF; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7A04A1E04C; Fri, 07 Nov 2025 12:26:53 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 799B11E04C for ; Fri, 07 Nov 2025 12:26:52 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0C45A3858C42 for ; Fri, 7 Nov 2025 17:26:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C45A3858C42 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=syntacore.com header.i=@syntacore.com header.a=rsa-sha256 header.s=m header.b=VgOwowYF Received: from m.syntacore.com (m.syntacore.com [178.249.69.228]) by sourceware.org (Postfix) with ESMTPS id DE7103858D1E for ; Fri, 7 Nov 2025 17:26:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DE7103858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=syntacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=syntacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DE7103858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=178.249.69.228 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762536374; cv=none; b=lq8nhLNv2GYRym9apiCOgsB2h7t7PBo43PWJSYmbQy2djRD6YFvdpcTVqcD4/mNroQHo0FQ4sZh0IvOniiuFes6Bd3yblh8u6hrKO4vaUtahkZZTz5k8W4AHyczgSZ6+ejc4kwBdLkbc2Tuen/EXo1nW24Lld8sm1Ux5iZqfLsk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762536374; c=relaxed/simple; bh=oTD8WT+YtBhvFYUKSn8MlBEeEzxUvjXL9yDyJkaJwAk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=oyPS1HLW0YyxZw0bnIMskjlm5DAt4lLnzW99RHL6FWA/3dNpRExWTFTE2/XEi+itgtQr0r7VvKzo27uyNQbR+z3bBbpfUzq96uXFObroRRhkncVsVvpvkIuf+W5oNmWfFXzKnPIq25ju4utTZPQoS9aC3//sNuJC9KSUZBAjXkQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE7103858D1E Received: from MRN-SC-KSMG-01.corp.syntacore.com (localhost [127.0.0.1]) by m.syntacore.com (Postfix) with ESMTP id D4A611A0003; Fri, 7 Nov 2025 17:26:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 m.syntacore.com D4A611A0003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=syntacore.com; s=m; t=1762536372; bh=sokTjgE1+62sCiYa7O4yJSD7/7/SZKM6BKYSScy69iw=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=VgOwowYFYFS+Li1nOgUD5EO24C7zO4NZoUN9nqBV6b81med9vx9P11iukyERUwugE /RNODQ2cQHzYG3c+7Xf9FfSaY2TIGSqLSKTzGXFYa+bnkonncnqqIem+PCQ8E46zMZ ikfqNYlfuOETos1WXPgwUXnvm+DXNhLaFTz2rhmYoss+DC1+BPdJmDAPWkhF4kKGVL DKJPKzJ58xT2Ujreo3RS5pGduWRxvXZVV/mEhMdy1Ivo0bJjqAuII6ImnByiJJOU5y +ONwQVPxf3Th+ucfJ91yBCGnUNS0kf0ObJSs+kEExaYFmQleQvwxLxhxXVgCUv0hbz hlaSSaZHO/qYg== Received: from S-SC-EXCH-01.corp.syntacore.com (exchange.syntacore.com [10.76.202.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by m.syntacore.com (Postfix) with ESMTPS; Fri, 7 Nov 2025 17:26:12 +0000 (UTC) Received: from ouran.high.school.host.club (10.178.157.72) by S-SC-EXCH-01.corp.syntacore.com (10.76.202.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Fri, 7 Nov 2025 20:26:08 +0300 From: Kirill Radkin To: CC: , , Kirill Radkin Subject: RISC-V Vector Extension Support Date: Fri, 7 Nov 2025 20:25:41 +0300 Message-ID: <20251107172542.1715385-1-kirill.radkin@syntacore.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250730105248.661381-2-snatu@whileone.in> References: <20250730105248.661381-2-snatu@whileone.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.178.157.72] X-ClientProxiedBy: S-SC-EXCH-01.corp.syntacore.com (10.76.202.20) To S-SC-EXCH-01.corp.syntacore.com (10.76.202.20) X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.1.8310, bases: 2025/11/07 16:52:00 #27893595 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: NotDetected, bases: 2025/11/07 16:47:00 X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 5 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Sameer, My name is Kirill Radkin. Like you, I have been working with my colleagues at Syntacore on RVV support in GDB. I've attached my patch in other thread (https://inbox.sourceware.org/gdb-patches/20251107165534.1688124-1-kirill.radkin@syntacore.com/T/#t), but I’d like to share some suggestions and possible improvements here. Here are some of the key differences and improvements in our implementation: - `create_feature_riscv_vector_from_features` In our implementation, this function is called `create_feature_riscv_rvv`. 1. Vector CSRs are added to `"org.gnu.gdb.riscv.csr"` instead of `"org.gnu.gdb.riscv.vector"`. Placing vector CSR registers in this feature is incorrect and breaks compatibility with OpenOCD (bare-metal targets), because it requires placing these registers in "org.gnu.gdb.riscv.csr". 2. Vector register types are represented not only as integer values, but also as floating-point values. - Defining VLENB We use the same approach with `asm ("csrr %0, vlenb" : "=r"(vlenb));`, but to guard this instruction we rely on the RISC-V hwprobe interface: features.vlenb = 0; static struct riscv_hwprobe query[] = { { RISCV_HWPROBE_KEY_IMA_EXT_0, 0 } }; if ((syscall (NR_riscv_hwprobe, query, 1, 0, NULL, 0) == 0) && (query[0].value & RISCV_HWPROBE_IMA_V)) { int reg = 0; asm volatile ("csrr %[vlenb], vlenb" : [vlenb] "=r"(reg)); features.vlenb = reg; } - Vector register cache Instead of creating a new cache for vector registers, we reuse the existing GDB regcache. Could you clarify why you decided to use a separate cache structure? - Structure for `ptrace` calls (`struct __riscv_vregs`) It seems a bit too large (256 KB). We faced the same issue and solved it with: struct __riscv_v_regset_state { unsigned long vstart; unsigned long vl; unsigned long vtype; unsigned long vcsr; unsigned long vlenb; char vreg[]; }; Later, when using it for `ptrace` (e.g., in `riscv_linux_nat_target::fetch_registers`), we determine the vector register size from regcache and allocate only the necessary amount of memory. - RVV support in gdbserver { PTRACE_GETREGSET, PTRACE_SETREGSET, NT_RISCV_VECTOR, sizeof (struct __riscv_vregs), OPTIONAL_REGS, riscv_fill_vregset, riscv_store_vregset }, If the vector regset is marked as `OPTIONAL_REGS`, we observed a kernel issue (https://lore.kernel.org/linux-riscv/20251007115840.2320557-1-geomatsi@gmail.com/T/#m87442da077efb7b7f6c0ccd3ee69a01f4e06791c): the vector context is not properly initialized until the first vector instruction is executed. As a result, when gdbserver tries to fetch the regset (`regsets_fetch_inferior_registers` from `gdbserver/linux-low.cc`), it gets `EINVAL` (instead of ENODATA as it should be) from `ptrace` and disables the vector regset. To avoid this, we marked it as `EXTENDED_REGS`. Another kernel bug we observed is that ptrace can return a zero vlenb in some cases (more info about and possible fix posted to linux mailing list here: https://lore.kernel.org/linux-riscv/20250821173957.563472-1-geomatsi@gmail.com/T/#u ). To avoid this issue, we added a simple workaround in gdbserver/linux-riscv-low.cc:riscv_store_vecregset. - RVV ABI support The main feature I’d like to propose is support for the RVV ABI, enabling GDB to call functions with vector arguments (`call`/`print` commands). Key components: 1. `struct riscv_vector_arg_reg` — tracks available vector registers for function arguments. 2. `riscv_assign_vec_reg_location` — determines which registers should hold arguments depending on their type. - Tests Our patch also includes test cases for RVV support. Best regards, Kirill Radkin