From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QL8gEssqS2iWYwsAWB0awg (envelope-from ) for ; Thu, 12 Jun 2025 15:30:19 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=JOiUPKj4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 43D9F1E102; Thu, 12 Jun 2025 15:30:19 -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,FREEMAIL_FROM,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 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 76D741E0C2 for ; Thu, 12 Jun 2025 15:30:18 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 187EC38844D0 for ; Thu, 12 Jun 2025 19:30:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 187EC38844D0 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=JOiUPKj4 Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) by sourceware.org (Postfix) with ESMTPS id 9AF183883974 for ; Thu, 12 Jun 2025 19:29:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9AF183883974 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9AF183883974 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1041 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749756578; cv=none; b=o13coaDYu3VdffJVsmj9bS/lPa5go8barRg0SMRSMzQ2p9KpiwhICVJAiTX/tfTjc4wNLziw61SVwL10lV+ofXSaml/KE12J1hgiJ4W6iLHTrU2XVsz40PyzSn1JRMWA4BuIzQHIR9VzSlbM026lYo0hiViS53y8HFJcX+fSfw8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749756578; c=relaxed/simple; bh=jdre3iWhENLiccK+xsSadh8VOcdBsaPNbdRZTpni9a8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=c9I0IkWpWiZ4psMu3VAT7quNvhmF7wpHa3BeL2QDv4afEMgGPoDyYNiDp0oSNS92ISTVDVh8sHy8UToDS7M9wED6f5ZqH7kB0FEiHzxARtZMG9GTv/eTVp7OK3U4DsQ1sF7+I0kvM0qopYfmZxexXYVvJUYm9AgjslIiQ947aN4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9AF183883974 Received: by mail-pj1-x1041.google.com with SMTP id 98e67ed59e1d1-313cde344d4so712975a91.0 for ; Thu, 12 Jun 2025 12:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749756577; x=1750361377; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:cc:to:autocrypt:from :content-language:references:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=sOE5wg8/OVgsmYAJVUOO0Nut4j2DGP2UX9iSNIbSgNw=; b=JOiUPKj4qCk8ay1GIOvqq5g1YfgZ49KSPPhKIzXfauT+u00XKROg03B7UOHJPvo9E1 iESEKHFUyydrfRc2yUbjuHmBAFegtFbWtjBFzHqwd5+Kq6z+Xha7swg2zrrl5d3rXpqx +67PIU9tDr/F4hz0lgfYupLotEaumV7rmpvA3ssAokArfSrPHTQtj2qPg35C2Uf0wNsy 7YUcuRkn0a/gtqw4DzWXw3DSBmbit9Cn4FR2l5q4VyuO90FzBWD/SnXf7mJs84FiyP1t X8VJOBMbcuBKV/8QUOxRGOlJ0KtoSW+YqbcEw39UI/SwSxRgiH+uG+0m6qtELDVhTI2b wXcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749756577; x=1750361377; h=content-transfer-encoding:in-reply-to:cc:to:autocrypt:from :content-language:references:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sOE5wg8/OVgsmYAJVUOO0Nut4j2DGP2UX9iSNIbSgNw=; b=Y47/if7KP3YhpNMXpyKSO2XzDlm3lyY89t0wGNLAXm1/zOreIfxUKg9m8pJ4VpRgS5 WyT23XlXW4Kc8sawlWbaJkB876Z/3vBjZWY4SB+jIoi+JhpgiDgPIhRAKPeYoJ5ggD+o KBsIJZX2bEUzt1O930ykApqEql3r78RY/0mweP0aKejFvLlzoMkvaS5UGytXpfiHzdTn D3eB78Tg0zJ8xWkp2Q/zcVhPcKxNt5el58Dg/1C0nhlRh7S+RWih3n7FmK42GvN3oc5S Br1V0A5HKtYzVyICZh5EYy4aLnz2O7UiHJBClxyHDRo34+JDN635kBWvI36hhk3wfoq0 8gWA== X-Forwarded-Encrypted: i=1; AJvYcCUdYve/kenOSStMllnrmLeXQBwko+76PZ0+oZ3965Xv/JNL3ekuSkAdnd0tuD6lJP5Qmh32gr3hU2ZASw==@sourceware.org X-Gm-Message-State: AOJu0YzcNMXstQdLwLCv8vABqK36xYVqDxz2hGssglJgfNjcDyb0yqU9 ti9zXZBcicBxx6ck5I5zeYq3Y53TiWWX3Lm09A2VyLKBRs8jjzKE7+ly X-Gm-Gg: ASbGncvo5g3qY5SV0QxqkTWGkHGBjOoT6Iv6fD+fn47BfBJYPfqFspF2E1H1yKxUJ2L fjGGRl3JSMA5YpuJ2DLpZkw60qPXX/L/qINI/4FQA3C4c6rnUxCDzusM6OQrJh84fwW8wDcHdQr vPjV6HYORXwW8+a4Kc6wRFsfpc36TRNyv7Bpx0e6KGekHvrfZ5ZTXQgYrDXQPA5NUvBzB1zjERP CLOYOuH632UnN2KIH2AOxtaHACZg3og9xMhMal71/d1C62J6PMJRfOQd3F9I67L5GkkckLhraMj KqiPdDEQrysG3rdAkkSVQholpCjKtWb3VaYfBmzwxb+gm022FmlTobbUcAs9BWI= X-Google-Smtp-Source: AGHT+IEZ54Hz0953eeQDCjodweF2dMUoSWSRu88Vl6viR6TP+rKRrLgeAY8d/Gf2HNidLQ43YnUtSg== X-Received: by 2002:a17:90b:1c04:b0:312:eaea:afa1 with SMTP id 98e67ed59e1d1-313d9ebc7aemr479073a91.29.1749756577440; Thu, 12 Jun 2025 12:29:37 -0700 (PDT) Received: from [10.2.0.2] ([89.187.185.165]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2365de78204sm825195ad.101.2025.06.12.12.29.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Jun 2025 12:29:37 -0700 (PDT) Message-ID: <40cede5f-1b8c-4eb9-b702-3805499efbf5@gmail.com> Date: Thu, 12 Jun 2025 14:29:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] gdb/alpha: Add target description support 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> Content-Language: en-US From: Yodel Eldar Autocrypt: addr=yodel.eldar@gmail.com; keydata= xjMEZxqXdhYJKwYBBAHaRw8BAQdAkletQdG3CLyANZyuf2t7Z9PK4b6HiT+DdSPUB2mHzmPN N1lvZGVsIEVsZGFyIChZb2RlbCBPcGVuUEdQIGtleSkgPHlvZGVsLmVsZGFyQGdtYWlsLmNv bT7ClgQTFggAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBNPNGM1AbbuKZqn435Xu T7c2ZU2sBQJnI9xJBQkB6nhTAAoJEJXuT7c2ZU2sSQABANuu74MJKexa8V8kVNLhw68loN4x 2ZbojcfUOWd8Pf5HAQDn1XxmQFPMIUYahlXMMrwRyQE1m6HjtrolOELICzwxDM44BGcal3YS CisGAQQBl1UBBQEBB0Ao8jLdb8MoWybV77fXOiqY5jSmrPy+MgzzjrAzqURjZAMBCAfCfgQY FggAJgIbDBYhBNPNGM1AbbuKZqn435XuT7c2ZU2sBQJnI9wMBQkB6ngWAAoJEJXuT7c2ZU2s BlUA/0ZfDDmzKdC1khPMaRIv/gWedFd5Z8jWqh0rswF2LyeNAQD6PjBgliBhL1xTto+juM1b jctqRusjtyMyzG8/ps2iDQ== To: Simon Marchi Cc: "Maciej W. Rozycki" , Yodel Eldar , gdb-patches@sourceware.org In-Reply-To: <3ef4c598-28d8-4c66-844d-58e5629415ab@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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! Yodel ------------------------ Diff of changes to patch ------------------------ diff --git a/gdb/alpha-tdep.c b/gdb/alpha-tdep.c index 60888a6f475..262a578b39c 100644 --- a/gdb/alpha-tdep.c +++ b/gdb/alpha-tdep.c @@ -1719,10 +1719,13 @@ alpha_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)        tdesc_data = tdesc_data_alloc ();        valid_p = true; -      for (int i = 0; i < ALPHA_NUM_REGS; ++i) +      for (int i = 0; i <= ALPHA_PC_REGNUM; ++i)         valid_p &= tdesc_numbered_register (feature, tdesc_data.get (), i, alpha_register_names[i]); +      valid_p &= tdesc_numbered_register(feature, tdesc_data.get (), +                               ALPHA_UNIQUE_REGNUM, +  alpha_register_names[ALPHA_UNIQUE_REGNUM]);        if (!valid_p)         return nullptr;      } ------------------------------------------------------- Remote registers with omitted TNR on anonymous register ------------------------------------------------------- (gdb) maintenance print remote-registers Name       Nr   Rel  Offset   Size  Type            Rmt Nr  g/G Offset  Expedited v0         0    0    0        8     int64_t         0       0 t0         1    1    8        8     int64_t         1       8   ... pc         64   64   512      8     *1              64      512 ''         65   65   520      0     int0_t unique     66   66   520      8     int64_t         66      528 ''         67   67   528      8     int64_t         65      520 *1: Register type's name NULL. ----------------------------------------------- Remote registers with TNR on anonymous register ----------------------------------------------- (gdb) maintenance print remote-registers Name       Nr   Rel  Offset   Size  Type            Rmt Nr  g/G Offset  Expedited v0         0    0    0        8     int64_t         0       0 t0         1    1    8        8     int64_t         1       8   ... pc         64   64   512      8     *1              64      512 ''         65   65   520      8     int64_t         65      520 unique     66   66   528      8     int64_t         66      528 *1: Register type's name NULL.