From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id l6PfE9VR1WTgUj0AWB0awg (envelope-from ) for ; Thu, 10 Aug 2023 17:08:37 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=dabbelt-com.20221208.gappssmtp.com header.i=@dabbelt-com.20221208.gappssmtp.com header.a=rsa-sha256 header.s=20221208 header.b=YOlJeFIQ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 47E871E0BB; Thu, 10 Aug 2023 17:08:37 -0400 (EDT) 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 0D9811E028 for ; Thu, 10 Aug 2023 17:08:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 76833385772F for ; Thu, 10 Aug 2023 21:08:34 +0000 (GMT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 426873858D32 for ; Thu, 10 Aug 2023 21:08:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 426873858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-686d8c8fc65so1056872b3a.0 for ; Thu, 10 Aug 2023 14:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20221208.gappssmtp.com; s=20221208; t=1691701701; x=1692306501; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=OXIUKkyCPEgNNkjTFW93aQW4gicEuSkO6Grvd3DkGHU=; b=YOlJeFIQE+/EcWIHVpcAqlbgQV+5IiHWL5Oi0Stq+k2jQDx89asfyWlZdejydVLfQj eaPCeNv8hYkA3ZcbQtvdUI0NWpt5OR0XvxgKm51fQuAaWnprMaCxrtPMQBUdFmJfy1RJ GhoUPJNF5fUKv00mWRZLSLHyuwVJFM5ovnb0+ArkZdlpCmjqNdkYMGVITZRznvF8o+7p O9HaXdJyI5DD5PJekN7nd/7xSDKGBvhVf0wTyOYDq6ym2oO+d1e1YIIQZgeByCPPm/2v 2Sm7SIi+EOzkeJZLElAX+BCwyQe5Cv+zJVttVReGFXAiMxBpAxZzN2lkfNig07YA23pS ztVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691701701; x=1692306501; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OXIUKkyCPEgNNkjTFW93aQW4gicEuSkO6Grvd3DkGHU=; b=Xy6w12sJcV7MBnKCHCv16jx5QN0lKrTRgxWMcLWnKBH9xmbDIe3NLzy4GmxUckD+Sb FfLt3izCSa0ONslMPvx01YJ7TcgVyQubLIoMDmHq80XAyWsZUuVWVK3HGlLGqMwpSaSE isBFBRLuRnv3Q0Ld4VmDZovTycKWF+d0Ykp4gLyUtJurx208nykHHFFZ5aXICbwHICYh QPScIZPmSu9XPOp8ivqG9a9aqlLTV7ILSvJo6+1PDfE6Cu/6j/vGHhLamoDmMxjReFMV M1uC3OBPxjxuPKoo9pWTQH0qNWR8NNsgK6nH/58FI2qaecJZTgcq4TKNQ61pfZCUDDxH 7a4A== X-Gm-Message-State: AOJu0Yx5PWwNRuZAWv05YHpYw96xiXJYCn0cZyHRdjjUAzPthaebX3k+ VW5uHLuCF8/lQMB1j5tleVgT3V/5I+mFXo9UYYA= X-Google-Smtp-Source: AGHT+IGjOmBAbPo3yGPRSJM8VsbKvqfLVq7Xn7SyNp67QktnBq3Ivr5cVQ+Z6W3nrAwAvvz5v4h0aA== X-Received: by 2002:a05:6a20:728c:b0:13d:ee19:771f with SMTP id o12-20020a056a20728c00b0013dee19771fmr232804pzk.8.1691701701061; Thu, 10 Aug 2023 14:08:21 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id k15-20020aa7820f000000b006877a2e6285sm1947607pfi.128.2023.08.10.14.08.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Aug 2023 14:08:19 -0700 (PDT) Date: Thu, 10 Aug 2023 14:08:19 -0700 (PDT) X-Google-Original-Date: Thu, 10 Aug 2023 14:08:17 PDT (-0700) Subject: Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native In-Reply-To: CC: macro@orcam.me.uk, greg.savin@sifive.com, greentime.hu@sifive.com, oleg@redhat.com, Paul Walmsley , aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, gdb-patches@sourceware.org, andrew.burgess@embecosm.com From: Palmer Dabbelt To: andy.chiu@sifive.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Thu, 10 Aug 2023 10:23:34 PDT (-0700), andy.chiu@sifive.com wrote: > On Thu, Aug 10, 2023 at 9:55 PM Maciej W. Rozycki wrote: >> >> On Thu, 10 Aug 2023, Maciej W. Rozycki wrote: >> >> > > 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. >> > >> > 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. > > On the other hand, ptrace is not so lucky. The kernel will return the > min of either user specified size or the maximum Vector size. It is > still safe if we consider SMP with the same VLENB across cores though, > which is an assumption made on Linux. We just need a way to get VLENB > on the system. > >> >> NB since this stuff went in with v6.5-rc1 and v6.5 hasn't been released >> you can still back out the problematic change as no one is expected to use >> RC stuff in production. Alternatively you can redefine NT_RISCV_VECTOR >> for a corrected ABI, but I think it shouldn't be necessary. You just need >> to act quickly as I guess there may be 1-2 further v6.5 RCs only and you >> have to get with that to Linus right away. We can have a release or two >> without NT_RISCV_VECTOR support for the otherwise included vector stuff, >> it shouldn't be a big deal. There just won't be support for the debug >> API. IMO that's the way to go: given that we're still finding breakagaes this late in the cycle it's likely we've got others. Like Maciej said, we should have gotten the GDB stuff in along with the Linux stuff to find the problems. So let's just remove the ptrace() and core dump support for vector, it's not been released so it's not stable uABI yet. We'll just get it right before committing it, that can be as simple as just one more release. >> >> CC-ing Linux ptrace/RISC-V maintainers now to bring their attention. >> >> Maciej > > Thanks, > Andy