From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.esisar.grenoble-inp.fr (mx1.esisar.grenoble-inp.fr [195.220.36.133]) by sourceware.org (Postfix) with ESMTPS id 443F43858D32 for ; Mon, 1 Apr 2024 09:14:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 443F43858D32 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=lcis.grenoble-inp.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lcis.grenoble-inp.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 443F43858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.220.36.133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711962862; cv=none; b=vd87kQXViN/I18kpG/2RUmbhMZXmT1PdQ2ZQQ6p24KwSRYD4Ge/Jtwbbqq3fHxk9RZBxa+NCCMaToHO7tLUD08Gqw5Yr2N3Wyn6uN8ZNdC66aVu/0WsUs1t1Iwc3gx7WuINHWsK2Y7n1AYXpFjUy8sp+BswY5NpCf2/95f2R+0Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711962862; c=relaxed/simple; bh=al/eBMMVCDVXb477eqDH4bQv6yWT6WcFf8Xhm314AXI=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=wEOL4UXawJNzszJLzwhG7QAgiywGC7KEb1l66WaflGRXVVcjOPGm9ALFpvmBT72IWvcKyEKgjxz/wzwJdtD5sQNveBIEXFS/wkimbPMmEHZkXkgueYAgAB8fxhqD3/aDieFeGkeToBYTCPmM4iR189QsHTmgu30iZm1cLojI4aw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by mx1.esisar.grenoble-inp.fr (Postfix) with ESMTP id 77602223AE0; Mon, 1 Apr 2024 11:14:13 +0200 (CEST) Received: from mx1.esisar.grenoble-inp.fr ([127.0.0.1]) by localhost (mx1.esisar.grenoble-inp.fr [127.0.0.1]) (amavis, port 10032) with ESMTP id a6yWxspqVaHC; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.esisar.grenoble-inp.fr (Postfix) with ESMTP id CED2C223AB5; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx1.esisar.grenoble-inp.fr CED2C223AB5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lcis.grenoble-inp.fr; s=249EBAA6-1FF3-11E5-9F2E-E6FCA23003BF; t=1711962852; bh=sUCIiTbj0PwpCdBzI7ANvNlaY3m2XRhA4ZM8x7VyFI8=; h=Message-ID:Date:MIME-Version:To:From; b=OgGizzUdn49+sprTZdwNJu9POjjDzv242hrMIgmG7RksX2TthtMeohXMuA1A0quRb DnPH0c+XNgBDLko+dMY4KlCJ7OWy7m35EUVYtk/YEd8bJLxnv+WI/CRKefmZMfvn03 i5XMu825ozRddXb9tfZOJBcLlOt5WLF73BGbH7Fk= X-Virus-Scanned: amavis at mx1.esisar.grenoble-inp.fr Received: from mx1.esisar.grenoble-inp.fr ([127.0.0.1]) by localhost (mx1.esisar.grenoble-inp.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id XpUrZju0ZChC; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) Received: from srv-zimbra.esisar.grenoble-inp.fr (unknown [172.21.100.139]) by mx1.esisar.grenoble-inp.fr (Postfix) with ESMTPS id AB8872239BC; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) Received: from srv-zimbra.esisar.grenoble-inp.fr (localhost [127.0.0.1]) by srv-zimbra.esisar.grenoble-inp.fr (Postfix) with ESMTPS id 8A2106E0156; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by srv-zimbra.esisar.grenoble-inp.fr (Postfix) with ESMTP id 7430F6E016E; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 srv-zimbra.esisar.grenoble-inp.fr 7430F6E016E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lcis.grenoble-inp.fr; s=249EBAA6-1FF3-11E5-9F2E-E6FCA23003BF; t=1711962852; bh=sUCIiTbj0PwpCdBzI7ANvNlaY3m2XRhA4ZM8x7VyFI8=; h=Message-ID:Date:MIME-Version:To:From; b=OgGizzUdn49+sprTZdwNJu9POjjDzv242hrMIgmG7RksX2TthtMeohXMuA1A0quRb DnPH0c+XNgBDLko+dMY4KlCJ7OWy7m35EUVYtk/YEd8bJLxnv+WI/CRKefmZMfvn03 i5XMu825ozRddXb9tfZOJBcLlOt5WLF73BGbH7Fk= X-Virus-Scanned: amavis at srv-zimbra.esisar.grenoble-inp.fr Received: from srv-zimbra.esisar.grenoble-inp.fr ([127.0.0.1]) by localhost (srv-zimbra.esisar.grenoble-inp.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id KLduEVdbEHwe; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) Received: from [192.168.1.19] (lfbn-lyo-1-2156-7.w90-66.abo.wanadoo.fr [90.66.80.7]) by srv-zimbra.esisar.grenoble-inp.fr (Postfix) with ESMTPSA id 461086E0156; Mon, 1 Apr 2024 11:14:12 +0200 (CEST) Message-ID: Date: Mon, 1 Apr 2024 11:14:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: specify sh4al-dsp register types To: Simon Marchi , gdb-patches@sourceware.org References: <20240331224045.682181-1-sebastien.michelland@lcis.grenoble-inp.fr> <8121bf38-bf7e-4af0-9e22-f15c1ad60731@simark.ca> Content-Language: fr, en-US From: =?UTF-8?Q?S=C3=A9bastien_Michelland?= In-Reply-To: <8121bf38-bf7e-4af0-9e22-f15c1ad60731@simark.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-04-01 05:25, Simon Marchi wrote: > On 2024-03-31 18:26, S=C3=A9bastien Michelland wrote: >> This avoids $pc and similar registers being interpreted as negative wh= en >> in the upper half of the address space (e.g. by x/i), which doesn't >> interact well with Xfer memory maps. >> --- >> >> Hi, >> >> This patch fixes a pretty funny issue for the sh4al-dsp resulting from >> $pc being typed as an int. When $pc is in the upper half of the addres= s >> space, `x/i $pc' would resolve to a negative value. At least in the ca= se >> of a remote target with an Xfer memory map, this leads to a spurious >> "cannot access memory" error as negative addresses are out of bounds. >> >> (gdb) x/i $pc >> 0x8c202c04: Cannot access memory at address 0x8c202c04 >> (gdb) x/i 0x8c202c04 >> =3D> 0x8c202c04 : mov.l @r1,r10 >> >> Affected registers are pc, pr (return address of a call), gbr (base >> register for some specific addressing modes), vbr (interrupt handler) >> and spc (return address after interrupt). >> >> It's not immediately clear to me why existing sh variants don't also d= o >> that. Maybe it should be considered an issue with the memory map, or >> maybe it's just a rare enough condition to not care. >=20 > Hi S=C3=A9bastien, >=20 > I would suggest including all that info in the commit message proper. > If I were to do some git-blaming and fall on that commit, I would > appreciate having all that info right there. >=20 > I checked a few other arches, and it seems customary for arches to > indicate that the PC register and some others should be typed as a > builtin_func_ptr (while the SP register and some others should be typed > as a builtin_data_ptr). The fact that the sh arch doesn't do it seems > like an oversight. >=20 > Another effect of having the pc typed as an int is that printing it wil= l > show it as a decimal, without symbol resolution. Hi Simon, thanks for checking this patch. I didn't think much of it but I do also get the decimal printing. > If you want to try to fix the behavior on all sh arches, feel free to d= o > so. But otherwise, the patch LGTM: >=20 > Approved-By: Simon Marchi >=20 > Let me know if you don't have push access and would like me to push it > for you. I'll submit a v2 to get that same behavior on all sh arches--it feels=20 better to have a consistent interpretation. I indeed don't have push access, thanks for your help. S=C3=A9bastien