From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RSgvJ7SKEWjFCQ0AWB0awg (envelope-from ) for ; Tue, 29 Apr 2025 22:28:04 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=aqKZ6qwq; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8ECFD1E10E; Tue, 29 Apr 2025 22:28:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED 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 D380B1E0C2 for ; Tue, 29 Apr 2025 22:28:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0B4463858C62 for ; Wed, 30 Apr 2025 02:28:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B4463858C62 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=aqKZ6qwq Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 92C683858D26 for ; Wed, 30 Apr 2025 02:27:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 92C683858D26 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 92C683858D26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745980049; cv=none; b=O2jY0x7a2b/87uAvola167+l668y1QQ+x55LZV6QMuvb+3/i3qmKmX1hrI3MtjZZz9Y2sCSrGw2Mp40K3Synudd63IEZQ9cj6jX/DARJSCGLqtsgdnwCiosxBJwKlm3K4+hftJYCp5azzPGw6ZWh5Z2gnm/aLTew7Gv1mQ9Bar0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745980049; c=relaxed/simple; bh=ihP1eF1YQXZX99CXgXTcb0zUxPUjdRlaCO21DSQbOAg=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=KZGcAToIXb9tklTp/Dvu82oJ7E1o/VtAYGgBMHxtdRfEpzVtBYB83sMgcx6Q1x9NbFmifDNv804WvyinUbOi5twZVL13hMXVoOW0QoE13FBHowJqCJtIqvmxU9vOS65E2DsDRSzteq6BFN6gjaYa0rVir0wW7SADgUEgZ0vRx9M= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 92C683858D26 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-7399838db7fso551617b3a.0 for ; Tue, 29 Apr 2025 19:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1745980048; x=1746584848; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gzrSnx0KvTcYEsTfNsMJEmdQeIauquogWgcdkBgQEqg=; b=aqKZ6qwqPbfG9H/CbwQaG01M4vnhLJjirAPxnSD9dUoP9FazO4Tm2N6+X39KViJ5c0 vHNHmqIqfYZew1s1SaL7J21nZbbXKLQoxtq+X0SDBpuhbIq3hwewxtz4k4mWE6hC6EMr AsZSH5MBKp3Hk6KStg6MCXqhhb2eSXp+azgAxZP45S6ylyBh6Mn3hYzNL232Ii2PHRbx 3W9W1nhw4m+l8mW11nqOEPLGZ3edtSlsk50Q8IY68CushTkxTeJXPgc7aEu8oga1T8pi WGBKmG11pKyRqFLqdhjOSrjy9HBdDYi0shF+GsEGAK0UfRDKBte3n0PIlisWqQy1nGfd xiJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745980048; x=1746584848; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gzrSnx0KvTcYEsTfNsMJEmdQeIauquogWgcdkBgQEqg=; b=emJdLwAnX/iQq2MubMBTAlPtxV1sLfh7pLgnyES6OyL8qA58ItJIrgkUidgFSP1018 bhyc96l32O5AlUvGohjh5uRop/7ScUQUXEb/Zihxprly2ltUyUeb5GmOYv0fHyAVOmoh 9jR1AZWFjnFDs6zlckJoLp5eQHBGpykk3kDlIpjLU/54fO+vLDE9S3MR8aptFyXBZW2/ pTlaehK28gHzG2UJPftJrwpxlEfe64sJKnBIJnZt+MHD6JOcdC/QkgnHR5DymnzY1byC U0pOEU9AyjoHkewQJ9fYQ80KcQmtixy/E6vQHDPnGigUKI84IVnU+CRNB7TSAK40f9Zw OG0w== X-Gm-Message-State: AOJu0YwNMlr5jKwcSABbwPVYF2DRYtZO3JykIQwbTSTg+LsAAyf8yllk wXdxpNmengJc2UvCNqHswZHa9xIWxJOwt48BQXV7/oNrEPdMqI3rchOgnBPsRtk= X-Gm-Gg: ASbGncvAYn+KjXROwHIajHJswsk5NepAj1tMXSFAdnR1kVsFvvYhMgwUp9IFwISW8AY vObK3kbLnzPziRMyg8u/KfEeAaoL5mz9W20sgHpjYEmWJzgpunfGAYJl+HjoPwRmu3ush5IAv4D UxIQb1j1gKeWSfpYMGwTSsRv8FGXSYlAnjFkk4/QHqJxQMeamTd4BBWVHhHTTIoHJb9B9p3AIyJ CybvU6rqTYMbp6fkabJaUyh+vAHgEJJONoe9A7duslYFlYsLWfeuoANqXCX20rt56w2cT/HHxah 1q5P0VPG36FULplItw1QZZYFFE15zZo1uchV X-Google-Smtp-Source: AGHT+IG4Ff7YfTADGANGn7Np3fquQk3U1D7S3Bv0efHW/p+MNkLVVGnEQYpqBN80BUvvAVhFw6ZBxg== X-Received: by 2002:a05:6a00:1305:b0:736:9f2e:1357 with SMTP id d2e1a72fcca58-74039ba96c7mr1668722b3a.12.1745980048557; Tue, 29 Apr 2025 19:27:28 -0700 (PDT) Received: from ghost ([2601:647:6700:64d0:6d65:72fe:c311:1245]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-74039a6318dsm469287b3a.148.2025.04.29.19.27.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Apr 2025 19:27:27 -0700 (PDT) Date: Tue, 29 Apr 2025 19:27:25 -0700 From: Charlie Jenkins To: Sameer Natu Cc: gdb-patches@sourceware.org, Greg Savin Subject: Re: [PATCH v3] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native Message-ID: References: <20250428072044.23343-2-snatu@whileone.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250428072044.23343-2-snatu@whileone.in> 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 On Mon, Apr 28, 2025 at 07:20:44AM +0000, Sameer Natu wrote: > From: Sameer Natu > > A v3 re-spin of the original patch. v4 now :) > Tested with latest kernel 6.14.2 on RISCV QEMU. > Removed Magic Numbers from v2 patch and worked on review comments of v2 patch. > > Co-Authored-By: Greg Savin > > --- > gdb/arch/riscv.c | 182 ++++++++++++++++++++++++++++++++++- > gdb/nat/riscv-linux-tdesc.c | 68 +++++++++++++ > gdb/nat/riscv-linux-tdesc.h | 24 +++++ > gdb/riscv-linux-nat.c | 162 +++++++++++++++++++++++++++++++ > gdb/riscv-linux-tdep.c | 133 +++++++++++++++++++++++++ > gdb/riscv-tdep.c | 49 +++++++++- > gdb/riscv-tdep.h | 6 ++ > gdbserver/linux-riscv-low.cc | 110 +++++++++++++++++++++ > include/elf/common.h | 1 + > 9 files changed, 728 insertions(+), 7 deletions(-) > > diff --git a/gdb/arch/riscv.c b/gdb/arch/riscv.c > index a6188ea3a8c..1a9699b8f79 100644 > --- a/gdb/arch/riscv.c > +++ b/gdb/arch/riscv.c > @@ -25,12 +25,30 @@ > #include "../features/riscv/64bit-fpu.c" > #include "../features/riscv/rv32e-xregs.c" > > +#include "opcode/riscv-opc.h" > + > #ifndef GDBSERVER > #define STATIC_IN_GDB static > #else > #define STATIC_IN_GDB > #endif > > +#ifdef GDBSERVER > +/* Work around issue where trying to include riscv-tdep.h (to get access to canonical RISCV_V0_REGNUM declaration > + from that header) is problamtic for gdbserver build. */ > +#define RISCV_V0_REGNUM 4162 > +#else > +#include "riscv-tdep.h" > +#include "defs.h" > +#endif > + > +static int > +create_feature_riscv_vector_from_features (struct target_desc *result, > + long regnum, > + const struct riscv_gdbarch_features > + features); > + > + > /* See arch/riscv.h. */ > > STATIC_IN_GDB target_desc_up > @@ -83,15 +101,171 @@ riscv_create_target_description (const struct riscv_gdbarch_features features) > else if (features.flen == 8) > regnum = create_feature_riscv_64bit_fpu (tdesc.get (), regnum); > > - /* Currently GDB only supports vector features coming from remote > - targets. We don't support creating vector features on native targets > - (yet). */ > if (features.vlen != 0) > - error (_("unable to create vector feature")); > + regnum = > + create_feature_riscv_vector_from_features (tdesc.get (), > + regnum, features); > > return tdesc; > } > > + > + > +/* Usually, these target_desc instances are static for an architecture, and expressable > + in XML format, but this is a special case where length of a RISC-V vector register > + is not architecturally fixed to a constant (the maximuim width is a defined constant, > + but it's nice to tailor a target description the actual VLENB) */ > +static int > +create_feature_riscv_vector_from_features (struct target_desc *result, > + long regnum, > + const struct riscv_gdbarch_features > + features) > +{ > + struct tdesc_feature *feature; > + unsigned long bitsize; > + > + feature = tdesc_create_feature (result, "org.gnu.gdb.riscv.vector"); > + tdesc_type *element_type; > + > + /* if VLENB is present (which we know it is present if execution reaches this function), > + then we know by definition that it is at least 4 bytes wide */ > + > + element_type = tdesc_named_type (feature, "uint8"); > + tdesc_create_vector (feature, "bytes", element_type, features.vlen); > + > + element_type = tdesc_named_type (feature, "uint16"); > + tdesc_create_vector (feature, "shorts", element_type, features.vlen / 2); > + > + element_type = tdesc_named_type (feature, "uint32"); > + tdesc_create_vector (feature, "words", element_type, features.vlen / 4); > + > + /* Need VLENB value checks for element chunks larger than 4 bytes */ > + > + if (features.vlen >= 8) > + { > + element_type = tdesc_named_type (feature, "uint64"); > + tdesc_create_vector (feature, "longs", element_type, features.vlen / 8); > + } > + > + /* QEMU and OpenOCD include the quads width in their target descriptions, so we're > + following that precedent, even if it's not particularly useful in practice, yet */ > + > + if (features.vlen >= 16) > + { > + element_type = tdesc_named_type (feature, "uint128"); > + tdesc_create_vector (feature, "quads", element_type, > + features.vlen / 16); > + } > + > + tdesc_type_with_fields *type_with_fields; > + type_with_fields = tdesc_create_union (feature, "riscv_vector"); > + tdesc_type *field_type; > + > + if (features.vlen >= 16) > + { > + field_type = tdesc_named_type (feature, "quads"); > + tdesc_add_field (type_with_fields, "q", field_type); > + } > + if (features.vlen >= 8) > + { > + field_type = tdesc_named_type (feature, "longs"); > + tdesc_add_field (type_with_fields, "l", field_type); > + } > + > + /* Again, we know vlenb is >= 4, so no if guards needed for words/shorts/bytes */ > + > + field_type = tdesc_named_type (feature, "words"); > + tdesc_add_field (type_with_fields, "w", field_type); > + > + field_type = tdesc_named_type (feature, "shorts"); > + tdesc_add_field (type_with_fields, "s", field_type); > + > + field_type = tdesc_named_type (feature, "bytes"); > + tdesc_add_field (type_with_fields, "b", field_type); > + > + /* Register vector and CSR definitions using stable magic regnums to > + ensure compatibility across GDB and gdbserver builds. */ > +#if 0 > + tdesc_create_reg (feature, "vstart", RISCV_VSTART, 1, NULL, features.xlen * 8, "int"); > + tdesc_create_reg (feature, "vxsat", RISCV_VXSAT, 1, NULL, features.xlen * 8, "int"); > + tdesc_create_reg (feature, "vxrm", RISCV_VXRM, 1, NULL, features.xlen * 8, "int"); > + tdesc_create_reg (feature, "vcsr", RISCV_VCSR, 1, NULL, features.xlen * 8, "int"); > + tdesc_create_reg (feature, "vl", RISCV_VL, 1, NULL, features.xlen * 8, "int"); > + tdesc_create_reg (feature, "vtype", RISCV_VTYPE, 1, NULL, features.xlen * 8, "int"); > + tdesc_create_reg (feature, "vlenb", RISCV_VLENB, 1, NULL, features.xlen * 8, "int"); > +#endif This prevents gdb from printing the csrs! I meant that you should replace all of the macros like "RISCV_VSTART" with "regnum++". - Charlie