From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 15MkGfTa32ZH9iUAWB0awg (envelope-from ) for ; Tue, 10 Sep 2024 01:36:52 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=gAVuB1Y1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1DBCB1E353; Tue, 10 Sep 2024 01:36:52 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-11.8 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=4.0.0 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 7CEA81E05C for ; Tue, 10 Sep 2024 01:36:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EDA40385C6C0 for ; Tue, 10 Sep 2024 05:36:49 +0000 (GMT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 87905385C6C7 for ; Tue, 10 Sep 2024 05:36:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 87905385C6C7 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 87905385C6C7 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725946587; cv=none; b=MKYfGHs+3Zob+7yc0A0pIbpO1wNq9kocXK44FsRkrIwhGJw9t/vixWtZujC4e1n5bXzrYfsxFMs0kATIOTYLStVI3x9J4Q8D3gqeBAZIuaEH7hW4AZhrkwSVenTKS9OobOSD0qWTRv1y9A9pEhqIVPekzVjWb0MMoxcE0qz76dw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725946587; c=relaxed/simple; bh=R5jyxoTnxyGuC2kCVU+G2YWKZHmFQFrZ2JsonLNrm24=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=wAK0V+hxqmyGEzN7wbFwCq/H4CnXx7GfFvqA//Zu15ibihpBah43hjhcb1LM7Zn2CwvVde1t2rBwdChmpu3KIb+lib3IK2XiIpFV9t/PF5sV1yARTMu8Axt06vps8EwBvuh01e083w4sflBre0NmfcV3EFaQkX9FHnMYYtIPp/g= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-2054feabfc3so45311425ad.1 for ; Mon, 09 Sep 2024 22:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1725946583; x=1726551383; darn=sourceware.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=7Jld002Oifcg2BjaUjHtbI9M0npba+8lAJUiEOxfYoE=; b=gAVuB1Y185opN9Meyo05LGAYnRuykMr9hGUC+nq91njrILwdi5Zqiru7xsQ7De01Py 7Pgt5iVhBKd3zCTQ1KwP0Ixar5Lpx6vtixqiLYEnS2kIzgKf/1OdqcniyE0r2z9O8Jfb k3bLGB4i/0UNF57mCcmATmqk87HrBjwoc0H/GPEqJ8zSzMe7Ww3ZyvNK8gj3Di6GEydK Cbm21oIbrCR+x3+77sloHxq7HK2jlbkK3FAV1A50bgJ9o+3XMyFO9RSqvS/jdA+tb0CD 4cJ/aK8TS78d2yREfWZgcEefM1Zv6Kst+iUY/l0OuUUkIv8E9KkL5ncryGHx/KGfI02i aFVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725946583; x=1726551383; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7Jld002Oifcg2BjaUjHtbI9M0npba+8lAJUiEOxfYoE=; b=LbtMDnijEN6omeOjwlTzPQR6QdNcI1nTMIQETJF1sVniORskPsY8PnhLoxN010Pv+m 2IMMgXjH/kL/BIx4KK96ng57hDf2r9dV1fsUX0lCy1lBH89ZbN0gxXn/2YxIhw88i43e Gy95x+42QFPZewy1oSsX3PfyEsrAnMlAuFmb0GvhwRaKkxqPfqigNQiJoGQ0HF/Ut1kT WFiKyqc9zGoA3voGYSXpfVxiRb6RiT6KOM+cp9EpHi6DFHqD0MO9TzvRM1Jl9tO5GKF1 O2/sz5To1R5kF8ug2uEX631zOe4X2aXagdnJQ5n2ZuPoCi2ti2WC5TZ+t5dogWC08QAY mL5Q== X-Forwarded-Encrypted: i=1; AJvYcCWrmHKJxHlBs0mWDdJ4G/efGM1K5LN7PqYooSwTTBaCC5zWoKTi7AcY/5FWJxFfTKJAGV81leXUi24Wxw==@sourceware.org X-Gm-Message-State: AOJu0YwFf2smlJncgqjpkteXjGhZSg71aCK/LreKwA9ry+jgVwwa475Y H0kGdiA8yDPIjeWjMJfNRed2Zfff5JbJdQZ4O4u1LlYkCKdElCt/E2jTVhP3Gy8= X-Google-Smtp-Source: AGHT+IFuEwMketR8sf2nORPFTAMSSQktwasTrkR4Dx1opc3WaaLu+Uf116f24Bpbo3e9GFepv0Gjbw== X-Received: by 2002:a17:902:ccd0:b0:203:a046:c676 with SMTP id d9443c01a7336-206f0364302mr182836225ad.0.1725946583186; Mon, 09 Sep 2024 22:36:23 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:8f6e:8f79:b71d:9a5e]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20710f3054asm41556815ad.251.2024.09.09.22.36.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Sep 2024 22:36:22 -0700 (PDT) From: Thiago Jung Bauermann To: "Willgerodt, Felix" Cc: Luis Machado , "gdb-patches@sourceware.org" Subject: Re: [PATCH v3 0/8] gdbserver improvements for AArch64 SVE support In-Reply-To: (Felix Willgerodt's message of "Fri, 10 May 2024 13:47:11 +0000") References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <4d5ffba6-4f8c-418d-ad29-67b5b95c7bd9@arm.com> <8734qth98m.fsf@linaro.org> Date: Tue, 10 Sep 2024 02:36:19 -0300 Message-ID: <878qw0oyss.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 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 I'm finally reviving this work, and will have a talk about it at GNU Tools Cauldron next Monday. If you are going to be there, we can discuss in person. "Willgerodt, Felix" writes: >> -----Original Message----- >> From: Thiago Jung Bauermann >> >> Thank you for your interest in this series! I think it's very important >> too, and it nags me that I haven't been able to finish it yet. I gave up >> on the approach from this patch series, which was to have a different >> target description for each register size, which implies a different >> target description for each inferior thread. >> >> I have a branch where I implemented support in the XML target >> description to specify a register whose size is given by a math >> expression involving other registers. This way, a single target >> description is enough for the whole duration of the inferior execution, >> and for all inferior threads. But it still has significant bugs, and >> only occasionally I have been able to get back to it and try to move it >> forward. I pushed what I have to the sve-tdesc-dynamic-size branch at >> this repo, if you would like to have a look: >> >> https://git.linaro.org/people/thiago.bauermann/binutils-gdb.git >> >> If you "git diff 1bdabb9e9fe8../sve-tdesc-dynamic-size" you can >> see the code. >> >> I think I will be able to work on it again in a month or two. If you >> think my approach is good and the branch is a good starting point for >> you, feel free to work on it. I'd be happy to collaborate. >> > > Thanks for the clarification. > I briefly looked at your branch, but I didn't have enough time to really > understand it yet. But I still wanted to give some feedback based on > my current knowledge and what you wrote. Thank you! > On x86 we will also need resizable registers. Though on x86, the > sizing information is only partially found in other registers. Some of > the sizing information comes e.g. from the CPUID instruction > (basically an instruction to query features of your CPU, no idea if > there is an ARM equivalent). I think this won't be a problem with my current approach. The basic idea is to encode a simple math expression in the description XML (using MathML notation). A register value will be referenced with a element, which specifies a variable. You could define a variable name to mean the information from the CPUID instruction or some other source. > And x86 would also need the full > flexibility of adding or removing registers I think. So would the > Intel GPU port, that is currently still a downstream fork. I don't address the possibility of adding or removing registers. I believe my approach doesn't make it easier nor harder to add support for it though. > I realize that this is mainly our problem. We will start working on > This eventually. Though I think any series touching generic code > should offer enough flexibility for all architectures. I wonder > if your new approach offers that (I actually don't know), > if it is only based on other registers and only offers resizing. I think my new approach adds flexibility in the sense that it allows for a new way to specify register sizes that is very flexible (simple math expressions using the contents of other registers, or even other kinds of information) while not getting in the way of additional approaches that may be added in the future, including the previous approach of per-thread target descriptions. > Though if it doesn't prevent adding additional input for re-sizing > and could live in parallel to adding/removing registers at runtime > it could be viewed as ok. Yes, I believe that is the case. I think it makes easier to add additional input for resizing, by way of new variables which can be used in math expressions that represent those inputs. And it could live in parallel to adding/removing registers at runtime. > But it makes me wonder a bit if the older approach isn't more > flexible for future architectures that want to use it. And it also > seems to be closer to the way GDB has already implemented. > Of course that doesn't mean we can't switch GDB to > a better solution at some point. > > So I am curious: What was your reason for switching to the > new approach? I think Pedro summed up well the main concerns with the per-thread target description approach for the case of SVE support: https://inbox.sourceware.org/gdb-patches/045c1e09-5b6d-22b6-df7a-39cfa339b0e1@palves.net/ I agree with him that conceptually SVE would be best modelled in GDB as a target description feature specifying variable-sized registers. It isn't like that in the way GDB is currently implemented (and also in this patch series we're replying to) because of practical concerns with the complexity of the ideal solution. There was also concern about adding RSP support for it if it's not the best approach, because when adding a new feature to the remote protocol it's not easy to change or drop support for it later. I had researched into how to implement this new approach before posting the first version of this patch series, but at the time I wasn't able to find a way in a reasonable amount of time. After this feedback, I decided to try again and this time I was able to find a way to implement it. That doesn't mean that per-thread target description aren't the best model for other situations. For instance, if a system has different processor models in a single core then it is the natural approach. Also, if in your case registers can be added or removed, maybe it's the best approach as well. -- Thiago