From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 List-Id: 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