From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WC+TMwI6S2gYdQsAWB0awg (envelope-from ) for ; Thu, 12 Jun 2025 16:35:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749760514; bh=/1TiQn2+Wbgp4sXZ5x1yR/WZlaxGWAb5A3U53p5SRY0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mVBqi7H6mhjDcUN5QiSdQ9QpjygrQ5wpyssx66SZu3CBficnB89bFBdRlcM+eiuua QzgF8TSNg91i1ExS5Q4yJpNr6nfUn9AQ5gvXeKmboog79eh+S3J/u4yfU1CwQlzpRO Gsl/VbjELXfQk2KSZkX7xBtoSvrVIPjJVl01bq70= Received: by simark.ca (Postfix, from userid 112) id BF6441E102; Thu, 12 Jun 2025 16:35:14 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=unavailable autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=m9nU6vdA; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=QreXBs0i; dkim-atps=neutral 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 05A351E0C2 for ; Thu, 12 Jun 2025 16:35:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 951193817D8F for ; Thu, 12 Jun 2025 20:35:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 951193817D8F Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=m9nU6vdA; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=QreXBs0i Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id D9D6B381F5C7 for ; Thu, 12 Jun 2025 20:30:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9D6B381F5C7 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D9D6B381F5C7 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749760220; cv=none; b=byRRRMOUIBYzAdEOEcTIjAUAJMbyuK3NKOdQrAeH/T92lU4arPnf/O+UyY/O1io4IBbqFHR/+FGmEmqJrfey68+rvCa3Smlk3itloCwidXRWusoHT8C7b5AvhVd/ps6MN962Q1yoPhiVAiG/n5hGs2eDiYRP6uiomgVSPyeD1KA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749760220; c=relaxed/simple; bh=/1TiQn2+Wbgp4sXZ5x1yR/WZlaxGWAb5A3U53p5SRY0=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=A8PoZyEQXfnGG7yX67BLCCqcxGXH2+B3WVzSUrq/pop+1WpJQBQQZx78neJ3yC82mQyrt3lDQGuAv5eeuaRoLKtj0hr/NDE6qadSMUDlIKeBT7jBl3pMKxHxNnbHKf5eRgM1IzaqWQEi3JtDKjrjakAzCBMRCi06dEoTwDk1KeQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D9D6B381F5C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749760219; bh=/1TiQn2+Wbgp4sXZ5x1yR/WZlaxGWAb5A3U53p5SRY0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=m9nU6vdAbSrKQ3ks7Et78f5D4MmF+u1zBINtTC+QFfkEkCvZr7DlZubfDSyzv2ZQa fGQDsepviW9keDoF+kf0qmDnYPoWEOsV4SNi4emrDke2xID/oXPksgnmJJPjDMmegx msW1RWgUqAj57meWkczeAMuiGRXGaXzNyYWilLxQ= Received: by simark.ca (Postfix, from userid 112) id 95B021E126; Thu, 12 Jun 2025 16:30:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749760217; bh=/1TiQn2+Wbgp4sXZ5x1yR/WZlaxGWAb5A3U53p5SRY0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=QreXBs0ihNLJv33OzyjCFxZaV+uZDWBRvYWrPxUnSOk79kgRkty/C/LLGZp6J3N41 jWTWSjGDa9XkqbT05tSzQP3y/zDiplyLMNN/d7s53sWr57Aq/m2H0As92KmPd4tZFo mu+SVQr9P5FP3szBC91Bdev7yoUfPkt2/DUDTFV8= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 58DFD1E0C2; Thu, 12 Jun 2025 16:30:17 -0400 (EDT) Message-ID: <869aca3b-78ab-4ec6-af23-56394c040d75@simark.ca> Date: Thu, 12 Jun 2025 16:30:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] gdb/alpha: Add target description support To: Yodel Eldar Cc: "Maciej W. Rozycki" , gdb-patches@sourceware.org References: <20250526151219.399450-1-yodel.eldar@gmail.com> <20250526151219.399450-2-yodel.eldar@gmail.com> <55cdf445-fee8-4e70-99c0-6d42eb68cd7d@simark.ca> <9feb7348-1dde-40cc-b21d-97671b8b3e39@gmail.com> <3ef4c598-28d8-4c66-844d-58e5629415ab@gmail.com> <40cede5f-1b8c-4eb9-b702-3805499efbf5@gmail.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <40cede5f-1b8c-4eb9-b702-3805499efbf5@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 On 2025-06-12 15:29, Yodel Eldar wrote: > > On 6/4/25 12:29 PM, Yodel Eldar wrote: >> >> On 6/4/25 9:49 AM, Maciej W. Rozycki wrote: >>> On Wed, 4 Jun 2025, Yodel Eldar wrote: >>> >>>>> Do we need to call tdesc_numbered_register for the register whose name >>>>> is ""? I suppose that we do, for backwards compatibility, when >>>>> debugging against a remote target that doesn't send a target >>>>> description? >>>> Hi Simon and thanks for your time and question! I think we do, because >>>> (IIUC) suppose an older remote target responds to, say, a 'p n' packet, >>>> but the anonymous register is unaccounted for by the client, wouldn't >>>> that break compatibility? Can't say for certain, so I defer to your and >>>> the community's wisdom and err on the side of caution as I investigate >>>> it. >>> Are there any remote Alpha targets there in the first place? >>> >>> I only have writing Alpha/Linux gdbserver on my todo list once I'm done >>> with the more urgent Alpha stuff (Linux kernel EV4 support restoration, >>> GCC LRA conversion) and I haven't heard of any other Alpha GDB RSP debug >>> stub either. There *might* be something in QEMU; I guess that'd be the >>> only place to check. >>> >>> Maciej >>> >> >> Maciej, you hit the nail on the head! Indeed, QEMU is the project I >> alluded to in the cover letter for the patch, and I have been using it >> for testing throughout the development of the patch. It also provided >> the impetus to write the target description for Alpha in the first >> place as it uses them for its execlog plugin. >> Thanks for taking the time to reply despite having more pressing >> Alpha tasks. I will keep an eye out for your forthcoming submissions, >> and provide my modest feedback if it's helpful. >> >> Yodel >> > > Hi Simon et al! > > Update regarding the feasibility of skipping the tdesc_numbered_register > (TNR) call on the anonymous register: > > I modified the patch to skip the TNR call (see below for diff), and ran > the "maintenance print remote-registers" command while connected to a > QEMU Alpha remote with "set debug remote on" and observed the following > (see below for the abridged command output): > 1. GDB internally creates a 0-bit wide placeholder at the anonymous > register's expected index (65), and that placeholder shares the GDB > internal offset of the unique register (520). > 2. GDB infers the anonymous register as its 67th register with > internal offset 528 and type int64_t. > 3. Despite having an internal number of 67, GDB does assign the > anonymous register the correct remote number of 65 and the correct > g/G offset of 520. > 4. 'g' and 'p n' packets (particularly, where n is unique's remote > number 66) do not appear to corrupt the regcache as I had feared. > > On the one hand, observations 3 and 4 suggest that skipping TNR on the > anonymous register could work, but the discrepancy between the internal > versus g/G offsets and the internal versus remote numbers (observations > 1 and 2) makes me wary of some hard-to-find side-effect that I may have > yet overlooked. Furthermore, 67 is the number of total registers, so > assigning 67 for the anonymous register's internal number (observation > 3) could be problematic. > > Moreover, having GDB implicitly account for the anonymous register at 67 > while also displaying a 0-bit register placeholder at 65 seems > gratuitous and probably offsets any performance benefit derived from > skipping TNR on the anonymous register. > > With regard to backwards compatibility, I compiled a 2011 version of > QEMU, commit b758aca1f6c, and performed the same experiment as above, > and the output of the maintenance command was identical to the recent > version used earlier. Likewise for the 2008 commit 19bf517b7f7 that > introduced GDB stub support for QEMU's Alpha target, although this > version had not implemented PALcode functionality and lacked the unique > register. Fortunately, all three did not appear to have problems > communicating with the GDB client, notwithstanding my concerns, but the > scope of my testing was limited to the QEMU targets, and I don't think > it qualifies as a comprehensive answer to the compatibility question as > my inability to find other targets does not preclude their existence. > > Thus, I recommend against the omission of tdesc_numbered_register on the > anonymous register. > > Please let me know how to proceed; should v2 of the patch omit the > tdesc_numbered_register call on the anonymous register? I defer to your > judgment. Thanks! Thanks for the detailed investigation. I'm not super familiar with register descriptions and the register numbering. I think it's better to be on the safe side and leave it there, it shouldn't bother anybody. >From my non-Alpha-expert point of view, the series LGTM, so I'm tempted to approve it. Maciej, did you have some comments on the code? Does it look good to you? Simon