From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xF0PJnu91GSH8jwAWB0awg (envelope-from ) for ; Thu, 10 Aug 2023 06:35:39 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=T2zcHfhW; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 92B181E0BB; Thu, 10 Aug 2023 06:35:39 -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 8468B1E028 for ; Thu, 10 Aug 2023 06:35:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DF56B3857701 for ; Thu, 10 Aug 2023 10:35:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DF56B3857701 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1691663736; bh=OjP8JdWZNc/EsPOyQ5jCeiy7seg0BMeumVWKROy6HSY=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=T2zcHfhWXpA8GiM+sSQlShOkYvcTL423r3QqyKVr6uGDFqToXybwo/5meoD1fMmID 4e+jnlOcH1sSuXO7kSFXxiAQQgPJ/S9aQwy0HXIDYYq4j3GADjIgJkVAZumcY2+laY 98V+V3NAqlsuAAE/HTwwGBPir8iv+xOO5Ar6edYw= Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 7892A3858D20 for ; Thu, 10 Aug 2023 10:35:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7892A3858D20 Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-686c06b806cso518122b3a.2 for ; Thu, 10 Aug 2023 03:35:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691663716; x=1692268516; h=user-agent: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=OjP8JdWZNc/EsPOyQ5jCeiy7seg0BMeumVWKROy6HSY=; b=LHj7K2TK2X4d6Y2he9pLxYQ5Z3Bb42vchXzJJxfC6poZK2RCkfk18kXAFD1kJrth+p gHiXOxyfQBJFAG5/OxuyaHqlWnvNHfdTyOB5fHYL6MGJE1alNcGaqDMUHLqzcC6Fl+eI bEGQZVqBT9HrFTR8MqqkLjp+tParkvhzZVS0hUNn2oPuUVE+qz96zw83XIU3h5onpdr+ 3zLG4H2AcoeUMql46iPOa5GZT4tcfi+NpQzQgaxqin/kLTdB/eTu1BeRNS+rAmnGuWrR Ygy52XpuPL5+ZJn/LImCffJNcoBH3rLL4KFKDs5UB4yujtIPrmNdHPGlpebETjKOKxoT CT3A== X-Gm-Message-State: AOJu0Yz2zIu4u6sKUAHKpNxVwnamx1QJDAaDdfHxj4EEm6E4rKzlhWvd 7K7Kfe6HhwvdkhdH/a0XkVFYVk7agv1pikWSSmM= X-Google-Smtp-Source: AGHT+IEOhlADr1IOej3h7Jr0IhA9XclJXdHCIdmBUXXhXy9WL8xs+mqkohfqGeY7xTvOqXddWX83WA== X-Received: by 2002:a05:6a00:23c2:b0:671:4b06:4ea7 with SMTP id g2-20020a056a0023c200b006714b064ea7mr2278413pfc.15.1691663716348; Thu, 10 Aug 2023 03:35:16 -0700 (PDT) Received: from hsinchu26 (59-124-168-89.hinet-ip.hinet.net. [59.124.168.89]) by smtp.gmail.com with ESMTPSA id j15-20020aa78d0f000000b00687dde8ae5dsm1183568pfe.154.2023.08.10.03.35.14 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Aug 2023 03:35:15 -0700 (PDT) Date: Thu, 10 Aug 2023 10:35:11 +0000 To: "Maciej W. Rozycki" Cc: Greg Savin , Greentime Hu , 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 Message-ID: <20230810103510.GA2509@hsinchu26> References: <20230803230110.904724-1-greg.savin@sifive.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.8 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 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: , From: Andy Chiu via Gdb-patches Reply-To: Andy Chiu Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Thu, Aug 10, 2023 at 12:09:17AM +0100, Maciej W. Rozycki wrote: > On Wed, 9 Aug 2023, Greg Savin wrote: > > > The SIGILL guard is being used as a wrapper around determination of the > > VLENB CSR, which is not part of the ptrace() payload for vector registers, > > at least as it exists at head-of-tree Linux kernel. GDB or gdbserver > > needs to know VLENB in order to construct the architectural feature > > metadata that reports an accurate width for the vector registers. If not > > for the VLENB determination specifically, and the lack of this information > > via ptrace(), then there would be no motivation for executing a vector > > instruction directly. It's a workaround, basically. I guess I could > > inquire in Linux kernel land regarding whether the NT_RISCV_VECTOR ptrace() > > payload could be enhanced to provide VLENB. > > I think the kernel interface needs to be clarified first, before we can > proceed with the tools side. > > I can see the vector state is carried in a REGSET_V regset, which in turn > corresponds to an NT_RISCV_VECTOR core file note. I can see that besides > the vector data registers only the VSTART, VL, VTYPE, and VCSR vector CSRs > are provided in that regset, and that vector data registers are assigned > a contiguous space of (32 * RISCV_MAX_VLENB) bytes rather than individual > slots. > > So how are we supposed to determine the width of the vector registers > recorded in a core file? I'd say the RISC-V/Linux kernel regset API is > incomplete. Does it make sense to you if we encapsulate this with a hwprobe syscall? e.g provide a hwprobe entry to get system's VLENB. We will have to increase and rearrange the buffer for NT_RISCV_VECTOR if we want to use ptrace as the entry point for this purpose. I am not very sure if it'd be too late to do though. > > A complete API has to provide `ptrace' and core file access to all the > relevant registers (vector registers in this case) that can be accessed by > machine instructions by the debuggee. That includes read-only registers, > writes to which via `ptrace' will of course be ignored. If a register is > a shadow only and can be reconstructed from another, canonical register > (e.g. VXRM vs VCSR) then the shadow register can (and best be) omitted of > course. Additional artificial OS registers may also have to be provided > that reflect the relevant privileged state made available to the debuggee > at run time by OS calls such as prctl(2); this for example might be a mode > setting which affects the hardware interpretation of a register set that > debug tools may need to take into account or the person debugging may want > to check or modify (e.g. REGSET_FP_MODE in the MIPS/Linux port). > > I've added the authors of the Linux kernel code and the RISC-V/Linux > mailing list to the list of recipients. Am I missing anything here? > > Maciej Andy