From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id C041D3858D20 for ; Fri, 11 Aug 2023 11:28:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C041D3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-4fe55d70973so2201925e87.0 for ; Fri, 11 Aug 2023 04:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1691753322; x=1692358122; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0yjUhmd36Rsf2srBU/TiioBiCFM53JBI1jUHGB1t5n0=; b=Ags1tvporP0kJQzrFLZikT9mijblxfWeIaeYI6qOMsZODGrfLuGiUCipZtW1LUJnZJ HHYWsoUz0mI8qGC+mzO6wHGe5wUstLg0l/PCryAs6CX93JLmWIKuScbvtABVmuN9mgEX rAU+zTZLN3EKaFiUSCG+zABvWwGuTbE5178BoHvLVFDDGsOF6Jvb3cjdM8hV/Amnmq+O t8nAI1oRkZArCU6Ir3Qon9c8vsJXGwvbuI0vwNbCHwT+1eMUPBhPF0cGq9w2lbCmqtRX zV/W1ujpsOtskDk/yadwIsOLQVHry7mzmpjehN+GUi7qAEdyNPL1fUUOHPWX4N0lFY/1 YEfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691753322; x=1692358122; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0yjUhmd36Rsf2srBU/TiioBiCFM53JBI1jUHGB1t5n0=; b=R3ss9WFg8PWSYnMooJuYySMkNpos6b41gO+UeddfhCo1nmhZsXl/CIBAZF6k1Wxqe/ A5rWotvxPK9XyFzSs5oBrt10GWj+9xDBJ3bKsKpPe/AGC4JACpSgCZJJ6NDFi7HcAvoS 4RTsAR4pT7+et1LjbsDKkwJ/F8kbqUDUptqWvhtqNYeRP2FIXSKOUnvvHde3QGj5yFBw 0RMXqoxCBbi537iPzRfgKgUdZbK5Fd++bu3BbP0B/F89A6J1EM9RilEAC6rMhxDDDj4J vHDcYoQLK8u7UBTVckRilgl85JmvRh8OkPUm+VokKAu0aj79+yvNWQ5sT8+0oSZNIArm uaHQ== X-Gm-Message-State: AOJu0YzzuOlj2pUrJ70PmEMk4smGp3IgeO1RHO/8LT9fCs8BsH8cjEV5 QSIFLx/cvWq9UOYAfKqy3sMugabhdjuFsM5UM49z9xWdXPcfgGxTVomMiQ== X-Google-Smtp-Source: AGHT+IEe6Il5VXbASq3yZu/bwh9LqpoMnvX6UcmmuFUBpdpMAxqo3brZn83Dgz+BFL9OJw0SW8tFRg2db9PY90LzFuk= X-Received: by 2002:a05:6512:3d9e:b0:4f9:dac6:2f3d with SMTP id k30-20020a0565123d9e00b004f9dac62f3dmr723221lfv.13.1691753322061; Fri, 11 Aug 2023 04:28:42 -0700 (PDT) MIME-Version: 1.0 References: <20230803230110.904724-1-greg.savin@sifive.com> <20230810103510.GA2509@hsinchu26> In-Reply-To: From: Andy Chiu Date: Fri, 11 Aug 2023 19:28:30 +0800 Message-ID: Subject: Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native To: "Maciej W. Rozycki" Cc: Greg Savin , Greentime Hu , Oleg Nesterov , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, gdb-patches@sourceware.org, Andrew Burgess Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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, Aug 11, 2023 at 5:21=E2=80=AFAM Maciej W. Rozycki wrote: > > On Fri, 11 Aug 2023, Andy Chiu wrote: > > > > > No, how do you expect it to work with a core dump (that can be exa= mined > > > > on a different system, or with a cross-debugger)? You need to chan= ge the > > > > API I'm afraid; it's unusable anyway. It's a pity the toolchain co= mmunity > > > > 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 fro= m > the size of the note; I would find that awkward. Agreed. > > 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. It is possible to mitigate this consideration with the proposed solution[1], by calling the ptrace twice. First we make a ptrace call to obtain VLENB in struct __riscv_v_ext_state by setting the argument iov.len =3D sizeof(struct __riscv_v_ext_state). Then, we can allocate a buffer based on the result of the previous ptrace to get the full Vector registers dump. > > Maciej [1]: https://sourceware.org/pipermail/gdb-patches/2023-August/201507.html Andy