From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id L5CUBzKAgmogVysAWB0awg (envelope-from ) for ; Sun, 16 Aug 2026 23:29:54 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=sifive.com header.i=@sifive.com header.a=rsa-sha256 header.s=google header.b=ea9/KSrX; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0DCC71E09B; Sun, 16 Aug 2026 23:29:54 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (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 0192A1E09B for ; Sun, 16 Aug 2026 23:29:51 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C58BC4BA2E24 for ; Mon, 17 Aug 2026 03:29:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C58BC4BA2E24 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=sifive.com header.i=@sifive.com header.a=rsa-sha256 header.s=google header.b=ea9/KSrX Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 5690B4BA2E07 for ; Mon, 17 Aug 2026 03:29:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5690B4BA2E07 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5690B4BA2E07 Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=2a00:1450:4864:20::12a ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1786937366; cv=pass; b=rR8hGUuN9hOtL8NN8Qe4LQdNtkRAVP0Ya4E0kvOr5vN7BhuzcprlhhUCbvUDub3REb9RycI5kG7Fw9XT7CjsEycNKb124QwVnmcfHiVBJtd6W/3X2o52uUQmW1/vZAsXk1emusz370GnEJomNzRTsN0Q41cefuBFB4dR1kYOpN0= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1786937366; c=relaxed/simple; bh=sRV3LO4tjqEluPcxk3/YcbDk+fNHzcAOlUtjch3ye38=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=jqPxax3zDcn18VmuUD2wgBAwWW0cFeeBdp1ydkY6B1kn1PuSmIvdIRmXjDIDTMGt+P3SdYo8i4fsu7zpOMDqjbBU3MnThQFCC9cBo6ttcVdiuufdboWnL4JEsVOh+gL6KnETaVdDHPfpyAVDSWumxbVuZw0U3J5fWiifi1ucpi8= ARC-Authentication-Results: i=2; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=sifive.com header.i=@sifive.com header.a=rsa-sha256 header.s=google header.b=ea9/KSrX DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5690B4BA2E07 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5b3119957f0so2602762e87.1 for ; Sun, 16 Aug 2026 20:29:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786937365; cv=none; d=google.com; s=arc-20260327; b=hqI58LrNYxzWuQkOQP+O+NZ6VGZs+fMw+A2SxImtQzay8WpkNGi/Ql4ItAHLxhvjA9 GFBWaqoXGXEiHUTuCgSGEyFFq5KQkKSS3IIZMUZ41zchscubs0I0EMIVsTjvp9UZDjOW 7EUQDSuHJqxXe7+GWPCXqpJp5TqiZaHG6NYmHH3CCpe7vtSlxLillaE/3BsTkBkun1gf EtUTMS8RhKePW6olBqk0x1+hO2jVGehLAjWC7+Sx8FWb14TKAlVo13/CQBcHMZZuc6OK 2nKzJ7IYujuJ0n//MguECWTbZC9lH79/ICRTmjKr+pNeuZO4bTowEyfktKWcO2vbhkHe vbWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ZNTX9Hult2p6mayy/9xsuTeGjy66pgnnGeXaq4Y86Wk=; fh=Z2rBi79peZoOXvTZnQaRTnzzTZgSNsOZV2zirwy9EKM=; b=pRIoEe9jhwl4u1RCk+V7YrhG3Fuc30ILO+qxJ33Y3zFjP3RG6SSGZMPNtPL87uK5dm WPw634NAFSwtClJFU4ILvFRyi041sH0P7SNo/3JhWEDQFlH6WWxP/E9LeEsHaryLjnGu T4+f+iKa40g4jpK2aBmLJGqpSL+f3dz1m2zdkG2PpULmBbUzIirO1yupQDnAuE4/+EHu naHBXS2uvpujcuShuDGc3HbuZUOlTPOu6PPHmh5ki3cNwHfa1dZD1KgzxghydSrJHs/G xas/N2+Rdpzw7EBIDsjxI9HSLbYvquJu+wuKfSpP0LCKKWy9SGO7A2BumKlINA52xRRN JcPA==; darn=sourceware.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1786937365; x=1787542165; darn=sourceware.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ZNTX9Hult2p6mayy/9xsuTeGjy66pgnnGeXaq4Y86Wk=; b=ea9/KSrXDk2SRUtZwDt9cLd543Lki/bXV4gB9CQEvQnTdA1ZIJ3FLSpf1ppcly513A 8oxnFo8g1x6I0pEJcfiUYap5FZkbYfFZtvwzmSOhcLw3w2BNvzPgEyWFY1vbAmOcnMDH IRxO+jfOkwbHhRjvVLgEkRQfrOj02GRl9pdMdzXnXdc5wxUbLm9Q+dOOQFWiU1Ref64m C4cm99FV0zoFlri3zhgVqqYWDAPgEZZh9SgtRqobKDl/fHuYs50ALGwFVli4IyctLzSI 6Lv8y5hMCZP28gYYnTvqRvF7pgnuiC1svzEWgYCLx683RofSACH1OFAoF7ONHoMKusAU EnDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786937365; x=1787542165; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ZNTX9Hult2p6mayy/9xsuTeGjy66pgnnGeXaq4Y86Wk=; b=hSeuFO5Lj3wEa+Iz9U2xmHTdIK6RdTcYMR4v4ZRWSenImoN/+avsGI9yxCD3iUn7SU TpzJZP0L3ifCLM8skxdp2tnlz+21Iy4caMXnSXjVO4AM3oOQldPcvRE9FRjo70PK4fJn kT5Z6mVkzrF8N3AM81N/4bnO1qMMThZvIu0+HrhAoY+TjqnuKmm7qXsg4dkyhL//8lQV LQRE913yqPlrXMbXVN6QSCtXXaD9zsjOHN+MKu5NaCmmN7m1wzz2o8vHxSfnE/Xfj8F4 KNxoZfjBXzyhS83GuR5akdVTORhMB0afbxnNAsS2Do+sEq0ZUJ7kVk9qvL+ZF34+pQGS ZJ0A== X-Forwarded-Encrypted: i=1; AHgh+RpTHC3WSKFgRZ+z3qGZRZFX7COhCSU0S+Hlbzb4+NyscoGiQxqPdosH4oTAWoqwW9m/gEPg+AylAp3Oow==@sourceware.org X-Gm-Message-State: AOJu0YyKhFlnohFtEKURSgtS5cMW6urhEu2awYq2pLNd3CBMOOdWP7Ni LY/r/8IGTzNCizzdRWUtHtcl4uv8Q3YkWdhQVKgqI3v+BUlVXSztNCK8Fpq5+0rCHRFvIEO3ApB CxbIvpZoOJ0JyEGm8NgMfyCtIgE0dOEF1ce4tp8kQ+EHRlS+t6RMNTMb7pg== X-Gm-Gg: AR+sD12ZB+58pmdknv6YW1+gDMF3dznF0ozp4wTrXekxLJbxvCjnh7SvSJKpISGReO/ EpNhTN/hVnoqtlq3NaQAAvTuYczmqMsi7UaxOuHV1FT19/gJ05qn6R6JxUA0Ur1ItFxgndnvUOE O6mdGD2mrrVPFHlkghUFdm/IMVJKN2WCtM3ZIQg0R/N09BCDvMVqQTiqhXnNC15qqUTFEgUPcQI SB8ycpiGFmrOOCW8Vf6R9rbYzY/VI+a4r4T52MoNK3jbJKktxBxVJVaMiHuhSE/9xLLINiM75D0 qDdEue+V6SIbe3y64MlrRg/10r/YyBFo3YkYZ7+gnKRZmGo= X-Received: by 2002:a05:6512:3da4:b0:5b3:e02:b3a3 with SMTP id 2adb3069b0e04-5b45913fe97mr3086177e87.13.1786937364977; Sun, 16 Aug 2026 20:29:24 -0700 (PDT) MIME-Version: 1.0 References: <20260811035205.26485-1-jerry.zhangjian@sifive.com> <877blxkpau.fsf@redhat.com> <87wltvulg7.fsf@tromey.com> In-Reply-To: <87wltvulg7.fsf@tromey.com> From: Jerry Zhang Jian Date: Mon, 17 Aug 2026 11:28:48 +0800 X-Gm-Features: AcwNN1WFGzJun_nrKzdMOpjMZYvZqYSuyf4Fk7pFZgo0SHvVznGeTKOoxYwCMJI Message-ID: Subject: Re: [PATCH] gdb: invalidate register cache after monitor commands To: Tom Tromey Cc: Andrew Burgess , gdb-patches@sourceware.org, kito.cheng@sifive.com Content-Type: multipart/alternative; boundary="000000000000e02850065935c66e" 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 --000000000000e02850065935c66e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew and Tom, Thanks for the review and for raising the interaction with the related remote-packet change. Andrew, you are right that the examples in the commit message were too broad. The concrete case behind this change is monitor reset halt: after GDB has cached a pre-reset PC, the target is reset and halted, but an immediate read of $pc can still return the old pre-reset value. A subsequent step or continue causes GDB to refetch the register and reveals the reset-vector PC, showing that the target reset succeeded and only GDB's register cache was stale. I will simplify the commit message in v2 to focus on this reset case and explain that the cache invalidation is needed because an opaque monitor command can change target state without GDB receiving a protocol-level notification. Tom, I checked the interaction with the related remote-packet change. This patch invalidates the register cache only after the CLI monitor command completes, so it does not run in the middle of an unrelated packet send or unwinding operation. Based on the current call paths, I do not think the two patches directly conflict, but I will make this scope explicit in v2 and double-check whether monitor packets sent through other paths need separate handling. I will also make the other requested cleanup changes: remove the Signed-off-by line; split the assignment out of the if and explicitly check proc_target !=3D nullptr. Thanks, Jerry Tom Tromey =E6=96=BC 2026=E5=B9=B48=E6=9C=8813=E6=97=A5=E9= =80=B1=E5=9B=9B =E4=B8=8A=E5=8D=884:34=E5=AF=AB=E9=81=93=EF=BC=9A > >>>>> "Andrew" =3D=3D Andrew Burgess writes: > > Andrew> I don't find any of these example particularly clear. They all > kind of > Andrew> hint towards a problem, but it would be nice to have at least one > fully > Andrew> explained case. > > I wonder also if this conceptually conflicts with your patch "avoid > switching threads for send_packet where possible". In that patch, you > mention an unwinder sending a remote packet during unwinding. If that > packet happens to be a 'monitor' command, then presumably something bad > will happen due to flushing the register cache while unwinding. > > Tom > > --000000000000e02850065935c66e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew and Tom,

Thanks for the review and for ra= ising the interaction with the related remote-packet change.

Andrew,= you are right that the examples in the commit message were too broad. The = concrete case behind this change is monitor reset halt: after GDB has cache= d a pre-reset PC, the target is reset and halted, but an immediate read of = $pc can still return the old pre-reset value. A subsequent step or continue= causes GDB to refetch the register and reveals the reset-vector PC, showin= g that the target reset succeeded and only GDB's register cache was sta= le.

I will simplify the commit message in v2 to focus on this reset = case and explain that the cache invalidation is needed because an opaque mo= nitor command can change target state without GDB receiving a protocol-leve= l notification.

Tom, I checked the interaction with the related remo= te-packet change. This patch invalidates the register cache only after the = CLI monitor command completes, so it does not run in the middle of an unrel= ated packet send or unwinding operation. Based on the current call paths, I= do not think the two patches directly conflict, but I will make this scope= explicit in v2 and double-check whether monitor packets sent through other= paths need separate handling.

I will also make the other requested = cleanup changes:

remove the Signed-off-by line;
split the assignm= ent out of the if and explicitly check proc_target !=3D nullptr.

Tha= nks,
Jerry

Tom Tromey <tom@tromey.com> =E6=96=BC 2026=E5=B9=B48=E6=9C=8813=E6= =97=A5=E9=80=B1=E5=9B=9B =E4=B8=8A=E5=8D=884:34=E5=AF=AB=E9=81=93=EF=BC=9A<= br>
>>>>= > "Andrew" =3D=3D Andrew Burgess <aburgess@redhat.com> writes:

Andrew> I don't find any of these example particularly clear.=C2=A0 = They all kind of
Andrew> hint towards a problem, but it would be nice to have at least on= e fully
Andrew> explained case.

I wonder also if this conceptually conflicts with your patch "avoid switching threads for send_packet where possible".=C2=A0 In that patch= , you
mention an unwinder sending a remote packet during unwinding.=C2=A0 If that=
packet happens to be a 'monitor' command, then presumably something= bad
will happen due to flushing the register cache while unwinding.

Tom

--000000000000e02850065935c66e--