From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cEuFG91U1WRyVD0AWB0awg (envelope-from ) for ; Thu, 10 Aug 2023 17:21:33 -0400 Received: by simark.ca (Postfix, from userid 112) id 60C851E0BB; Thu, 10 Aug 2023 17:21:33 -0400 (EDT) Received: from server2.sourceware.org (ip-8-43-85-97.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 50B251E028 for ; Thu, 10 Aug 2023 17:21:31 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EB1C63858288 for ; Thu, 10 Aug 2023 21:21:30 +0000 (GMT) Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 2DF423858D32 for ; Thu, 10 Aug 2023 21:21:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DF423858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id C0CA99200C1; Thu, 10 Aug 2023 23:21:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id BA7BA9200BF; Thu, 10 Aug 2023 22:21:17 +0100 (BST) Date: Thu, 10 Aug 2023 22:21:17 +0100 (BST) From: "Maciej W. Rozycki" To: Andy Chiu cc: Greg Savin , Greentime Hu , Oleg Nesterov , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, gdb-patches@sourceware.org, Andrew Burgess Subject: Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native In-Reply-To: Message-ID: References: <20230803230110.904724-1-greg.savin@sifive.com> <20230810103510.GA2509@hsinchu26> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 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 Sender: "Gdb-patches" On Fri, 11 Aug 2023, Andy Chiu wrote: > > > No, how do you expect it to work with a core dump (that can be examined > > > on a different system, or with a cross-debugger)? You need to change the > > > API I'm afraid; it's unusable anyway. It's a pity the toolchain community > > > wasn't consulted if you weren't sure how to design the interface. Better > > > yet it would have been to implement the GDB side before the kernel part > > > has been committed. > > I just took some look into the code and here is what I came up with. > Actually, you know VLENB in a core dump file. The size of > NT_RISCV_VECTOR in a core dump file just equals sizeof(struct > __riscv_v_ext_state), which is 40B, plus VLENB * 32. So, the debugger > can actually calculate VLENB and resolve placement of V registers by > subtracting 40 from the size of NT_RISCV_VECTOR in a core dump file. Fair enough, I didn't dive into Linux code deeply enough to figure out that the size of an NT_RISCV_VECTOR core file note is indeed dynamically calculated. Most notes are of a fixed size, but we also have generic support for variable-size ones in GDB, so handling this case should be reasonably straightforward. OTOH VLENB is a program-visible register, so I think it will best be provided explicitly regardless rather than having to be reconstructed from the size of the note; I would find that awkward. NB I have been a bit concerned about the unusually huge allocation size of 256KiB+ for the register buffer required for ptrace(2), but I guess we'll have to live with it, because any solution that makes it dynamic would also complicate the interface. At least we won't waste filesystem space for any extraneous allocation in core dumps. Maciej