From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FCllJDlsCmhWkgMAWB0awg (envelope-from ) for ; Thu, 24 Apr 2025 12:52:09 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=QO8I0RrP; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 88A9A1E10E; Thu, 24 Apr 2025 12:52:09 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 1B4DD1E0C0 for ; Thu, 24 Apr 2025 12:52:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B70273858CDA for ; Thu, 24 Apr 2025 16:52:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B70273858CDA Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=QO8I0RrP Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 50F563858D21 for ; Thu, 24 Apr 2025 16:51:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 50F563858D21 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 50F563858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745513481; cv=none; b=KdxX/hWu2KGTqN/5dGqyW2jowi0hDt4L4sJ5G6cHVQ6u+vPf8meYrCpOnvLAGsQyqi368t3pbrSqNaJuorLYM9X53U50aBidtmGeTguUqhMNtT8RG4sbrUy1NphoqGOf+UiBOWMqJRAwugMPuWhCxguSiKpCDl4s3eufBm6W39E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745513481; c=relaxed/simple; bh=Zr0A5pnTrS8mMacZ6kLM5b5ob+j1C0E/y3+iRrn4nB4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xLbmrkCoL0v//AbVvQE14wh7xwdy+aM0t+K76V2tv1Rz2uOWrS8ok89lPl4aq80I5hvHLQvoElaO0rhVrKV3kJJRphq2G6cJ0+0IPU9LJTwG9qIazFXqRHgNkD4mUnakh3XpD2LgsFy0unGUZW4TL1azDoFkr+uPOPFen/ILU84= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 50F563858D21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745513481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hY0EQiDW6z/Vs4WYNEBlEP1jd4St11q4nytFA9G3Mhg=; b=QO8I0RrPw2lrIzvIz1h7N85fhDVszEzFLtvHCEYRP22cu3BkYQgnJzeerVm7Rph4y2hAzW 86Zcje225LlRFS+jXF9xehssdWAUFvBRm0b2p0lJnQLk/HoKohqfehTDKnGIHcs78X7O+s tkg60IxijbvP9s85Dj1kOI1B0atr9lo= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-149-g98ATxdQNCezd_bOn_LgzQ-1; Thu, 24 Apr 2025 12:51:17 -0400 X-MC-Unique: g98ATxdQNCezd_bOn_LgzQ-1 X-Mimecast-MFC-AGG-ID: g98ATxdQNCezd_bOn_LgzQ_1745513477 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-3912539665cso1022318f8f.1 for ; Thu, 24 Apr 2025 09:51:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745513476; x=1746118276; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hY0EQiDW6z/Vs4WYNEBlEP1jd4St11q4nytFA9G3Mhg=; b=BJYIUQa+vE+YsFXuP2h313t8Fgxr2Ae7/LDDmQ3MJhv/VYbT92THUfEYJTW/k18J0H H+6VpMPSRT7MXvAwIiHIwmjVNBggBH9qCTB8q7OG/NZJiX8HANvHECUy2wZlCYPly4N3 ReHo8ZxcRFY8BjJ7HseIvuIVWrH6Rblfi2fRwbPHRQ2ALlGZAj4m9VpBtzdUmYNtfnOX BZJaPT8RiHj2K/dlw0U0zi0L17mXRVjVASEUVv1iRLPHzjGCQLBuOqkmL3ziRLFp04Tp 6Stjnb4y7nUU091VAzjxs17UnO41pF3+UTpn+nWEM3IZUSNXFXUjdXB2Ce07jK0oF8Ul yfoQ== X-Forwarded-Encrypted: i=1; AJvYcCX8e2gkqgMMSGIBJm1FcFVkHJQrJ94ENEc04VL2pLLFzWScr9w6tZ+QzUiT93OlHIdANpWFltVuHjuUrg==@sourceware.org X-Gm-Message-State: AOJu0YzNFqyj3xB19h6wOgPEZaiubzkX71n/p+qdi5yYUZiEdoWBtkZF Coz4sh87pTT8pomBd/ccqV0ucKZHPLDHnKWeuoQb1TbC8AjX6HnWavXQJs9d90wJ93imogH5+Oh uz86JsyEO9KQ15EnzClDZNt7IoYE8xHVdp95/knlFJJEKfGbug+M7UqpZ04rNQAmQo0g= X-Gm-Gg: ASbGncs+BTxgj3Znkv0LWSAK91YeKKYtnt/EJzhMRxhYOfaEZ/FNOD1PdaVqirFJi36 RCQF5g+zTU5SXBEc2Io0p3NYz8o+j6eQp10Pftg4sc3uFG+Tk9PQN9JNZRUGxokMotYSWm8lfR4 +hUv6DUchJgUUfvVFfOAeOMjzvj4w8+NCT5i7QiEL0IyCnB1eTUQoEClQg8zxBC0WXdS9cx1J6Q /Hd5M4ZpXNVdfYuhPDDkMMxbGYo+zw5TV5ewIlegmoxSCzvuyp6tDK7lXh+rBN1hJo18QXEhX/6 99sVhkEgfP80GW5km38GgZRXEbCUF5yj22no X-Received: by 2002:adf:f942:0:b0:39c:e0e:b7ea with SMTP id ffacd0b85a97d-3a06d6957cemr2827514f8f.20.1745513476329; Thu, 24 Apr 2025 09:51:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGGM2zYG8fDwBbnMyJfBT+sALSK1j2Eb5XoYCx/Q0NdV4/7M7oE9hSYO/NZvUcMZ/8fr0anfQ== X-Received: by 2002:adf:f942:0:b0:39c:e0e:b7ea with SMTP id ffacd0b85a97d-3a06d6957cemr2827494f8f.20.1745513475855; Thu, 24 Apr 2025 09:51:15 -0700 (PDT) Received: from localhost (30.226.159.143.dyn.plus.net. [143.159.226.30]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a06d532744sm2678000f8f.69.2025.04.24.09.51.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Apr 2025 09:51:15 -0700 (PDT) From: Andrew Burgess To: snatu@whileone.in, gdb-patches@sourceware.org Cc: Sameer Natu Subject: Re: [PATCH] [PATCH v3] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native In-Reply-To: <20250424121915.1203050-2-snatu@whileone.in> References: <20250424121915.1203050-2-snatu@whileone.in> Date: Thu, 24 Apr 2025 17:51:14 +0100 Message-ID: <87selx7bb1.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 1CvByp0kUPLs22OBNgOC4YCumTx5apYld0UNhA1Tz3k_1745513477 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 snatu@whileone.in writes: > From: Sameer Natu > > A v3 re-spin of the original patch. > Tested with latest kernel 6.14.2 on RISCV QEMU. > Removed Magic Numbers from v2 patch and worked on review comments of v2 patch. Thanks for picking this up. It would be amazing to see vector support land in GDB. I'm a little rushed right now, I'll try to do a proper review soon, but I do have some immediate questions related to register numbering, see below... > diff --git a/gdb/arch/riscv.c b/gdb/arch/riscv.c > index a6188ea3a8c..14fc85631e3 100644 > --- a/gdb/arch/riscv.c > +++ b/gdb/arch/riscv.c > @@ -25,12 +25,38 @@ > #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. */ > +//#include "riscv-tdep.h" > +#define RISCV_VSTART 73 > +#define RISCV_VXSAT 74 > +#define RISCV_VXRM 75 > +#define RISCV_VCSR 80 > +#define RISCV_VL 3169 > +#define RISCV_VTYPE 3170 > +#define RISCV_VLENB 3171 > +#define RISCV_V0_REGNUM 4162 > +#else > +#include "riscv-tdep.h" > +#include "defs.h" > +#endif I'm curious why these constants are needed in here at all? It's been a while since I worked on this corner of the code, but my understanding is that the register numbering in the target description shouldn't have to match any particular number at all, it's just a unique id to tell the registers apart. The riscv-tdep.c file will then map the unique id assigned here to GDB's internal register numbering. Now, there is a bit of a nit here; the existing xml files do include a fixed numbering, and this was to work around some issues with early tool versions that didn't send an XML target description, but instead assumed a fixed numbering. Thus, they relied on GDB always asking for register number X when asking for e.g. fflags register. My understanding is that QEMU has correctly been sending XML descriptions for risc-v for a while now, so the fixed register numbering should no longer be needed, but critically, I believe any version of QEMU that has vector register support, has XML target description support, so we really should be free to use any register numbering we like here. Like I said, it's been a while, so maybe I'm forgetting something. If I am, could you explain more why the fixed numbering is needed here. > diff --git a/gdb/riscv-tdep.h b/gdb/riscv-tdep.h > index ad1e9596b83..7b41dfbdcbc 100644 > --- a/gdb/riscv-tdep.h > +++ b/gdb/riscv-tdep.h > @@ -46,6 +46,15 @@ enum > RISCV_LAST_FP_REGNUM = 64, /* Last Floating Point Register */ > > RISCV_FIRST_CSR_REGNUM = 65, /* First CSR */ > + > + RISCV_VSTART = 73, /* Vector start position. */ > + RISCV_VXSAT = 74, /* Fixed-Point Saturate Flag. */ > + RISCV_VXRM = 75, /* Fixed-Point Rounding Mode. */ > + RISCV_VCSR = 80, /* Vector control and status register. */ > + RISCV_VL = 3169, /* Vector length. */ > + RISCV_VTYPE = 3170, /* Vector data type register. */ > + RISCV_VLENB = 3171, /* VLEN/8 (vector register length in bytes) */ > + > #define DECLARE_CSR(name, num, class, define_version, abort_version) \ > RISCV_ ## num ## _REGNUM = RISCV_FIRST_CSR_REGNUM + num, Notice that RISCV_FIRST_CSR_REGNUM is 65, so vstart -> vcsr will overlap with the RISCV_CSR_*_REGNUM constants. Why not use the existing constants? Then vl/vtype/vlenb don't seem to match with the existing CSR constants, unless I'm doing something wrong. What's that all about? What I suspect here is that this is evidence that what I say above (about not neededing fixed numbering) is correct. In the generated target description we're using these incorrect(?) register numbers. But in riscv-tdep.c we map these to the correct CSR numbers. Fetching register state will be done using the actual CSR number, so it'll all work out. Anyway, any additional insights into the register numbering in this patch would be great. Thanks, Andrew