From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BeUbDwvkempErxwAWB0awg (envelope-from ) for ; Tue, 11 Aug 2026 04:57:47 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=e5g7RGlz; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2878A1E166; Tue, 11 Aug 2026 04:57:47 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 6AA1C1E033 for ; Tue, 11 Aug 2026 04:57:45 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9375B4BA9036 for ; Tue, 11 Aug 2026 08:57:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9375B4BA9036 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=e5g7RGlz Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id D6FCC4BA9011 for ; Tue, 11 Aug 2026 08:57:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D6FCC4BA9011 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D6FCC4BA9011 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786438639; cv=none; b=lybN7R0DVZIHFYY5IwYUTrNUB/jU23wHOe+t++RunwCO5wLW+ou9HnznIIwdUq8D9wh+add+/U04mBywpXfnnslC2CpJRUX20goTDUTbvWvQw4f9v57tl5vk2GVW0NVbj1/TqDmvU5Jtq81WTDPqADJgNpe9qKNBLwvIT0JKaqw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786438639; c=relaxed/simple; bh=a4RYKrC+xbq1Iy+xT5Yer0l8eGhGosTrXJWF4DeHeno=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=D2oq7L5gdhQyR5DZ7X2l7WSq8l2jlJYQEsQvoaZ4nLiwwyKHJRPuA0wSMJD9dpNSsZtIvpoelQwuzGUDMDvt73PRtophmXM0D7T96R/8e7ifWZJ2/NTU4gHMBD4olqBP+V/dYhGisgQ/VuNwBKUUQGXt7xXSz+gi9YAI3kYr8zI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=e5g7RGlz DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D6FCC4BA9011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786438638; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=veyS6DjiA5hF+INUjTCut0M+E38RC/jWfXZl1dy6RhU=; b=e5g7RGlzx7GmNn0uiAKYvYnQmmSl9yvwIP5vHl8LuJ3nI8xNsrWPbVbIMWnruykPg51doN 3aOR7+VJTpV/bpYnnN4teMi3gUPlu3MECdsjDujevEeE6rujuJySvsVMorVHFC9YJd94l5 vdaqoyJnhj9mie8IWHp4SoU14KylZ24= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-527-RTuI3e8ANWGqb-dfjJM00Q-1; Tue, 11 Aug 2026 04:57:16 -0400 X-MC-Unique: RTuI3e8ANWGqb-dfjJM00Q-1 X-Mimecast-MFC-AGG-ID: RTuI3e8ANWGqb-dfjJM00Q_1786438636 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4954c2d4081so21737595e9.2 for ; Tue, 11 Aug 2026 01:57:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786438636; x=1787043436; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=veyS6DjiA5hF+INUjTCut0M+E38RC/jWfXZl1dy6RhU=; b=X4boo0x6wtRDmRUC0Vaz5r6uBMYGg1pXLZZ0mDur3lVnIMLTxPsZquocxueN0v2NKN cTpeHDLn1hSAKobpcDDhTYZIUleA7xV2E91gafvd+Pa6SJNx1fdgBZwgef33PVgLiXa0 MvlkXpZ8O4ALa29bvP3fW3ZJWg5Zwx6PXmZ6pP+Y6j4Guk+2mkwCtrXhT3NMp1+qQeo5 ElO4ACB24ZMW0uYiZm3ynxa2KQGgWTX9YpeSAALvoqUdFHuAlxlAHMmaxPBkBCioPYJF 30vZs6HbFliugfq2BXmLBxk8s6xyYCkmo+uGrYRkRpj2ln4+FRE8sUEiUPlDGaL0TXmU oaAw== X-Forwarded-Encrypted: i=1; AHgh+RpsGJSoLCKI4zTfEC5xgzdAJB7gEbCzmmAkoosUOCwiFoCuN2LCshhGrOf9Ji9rY7ujXqgGkb21/LHESQ==@sourceware.org X-Gm-Message-State: AOJu0Yz/oca2VY5Ur6XvRgADjCnb2twHKHTGpanpngH0EJzsCrDhx9KF ENXyejA1bZw0JA7GRmYZyzJVkDbWtpxGocFJ3QkDPGmQNm851Vf+Mib3BOSHRokIyoWXxpMwJhT s9TK9qbMpuxZSMEqHPqgd9T7Q+2XAH+OmUA97LGwP5wZZWEyfB0MeMk40//GnfZ1cLMUMjmw= X-Gm-Gg: AR+sD108fmyk5HtOucPmSmcgLUTLh1Zyb8ip5bemBCSWXt1V9F8hiLLkcOrwBzM/84A NdK4lYKUyu2CzPSTd7O1YrJc4neS4Ym6bcRFsyA3TWmHu0x66YnMu5xxuqwI8wFSeV3t0aGwhPd e+eabwqgw9KYiXoOiq2dDmBwNWTofPryaI6jeRSUFWecTZgK1dkK3fhPsxRmI7eoPrjUTcR1RXH FcmbhMf0lUWoaEB+VEz+ZFYr4um9ItpHulSM8hGy/l08auP2SWCSyaJHblRXzz8F37gEZHHSTlY /DBLFjZJ7ov76NAwlbOjY7sxt4ra1c99IMQl3nl66cwdCj0Rd/XxvXix1xMYp1nF9e9ca8BK X-Received: by 2002:a05:600c:3e8e:b0:496:bbce:f3 with SMTP id 5b1f17b1804b1-499784398b3mr33654015e9.6.1786438635638; Tue, 11 Aug 2026 01:57:15 -0700 (PDT) X-Received: by 2002:a05:600c:3e8e:b0:496:bbce:f3 with SMTP id 5b1f17b1804b1-499784398b3mr33653195e9.6.1786438635135; Tue, 11 Aug 2026 01:57:15 -0700 (PDT) Received: from localhost ([31.111.209.128]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4814a72a1fcsm2738197f8f.33.2026.08.11.01.57.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 01:57:14 -0700 (PDT) From: Andrew Burgess To: Jerry Zhang Jian , gdb-patches@sourceware.org, kito.cheng@sifive.com Cc: Jerry Zhang Jian Subject: Re: [PATCH] gdb: invalidate register cache after monitor commands In-Reply-To: <20260811035205.26485-1-jerry.zhangjian@sifive.com> References: <20260811035205.26485-1-jerry.zhangjian@sifive.com> Date: Tue, 11 Aug 2026 09:57:13 +0100 Message-ID: <877blxkpau.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OUEiep5tXp8aXXonBdZoYVundAAOQBCYjYCcsUYgQGo_1786438636 X-Mimecast-Originator: redhat.com 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 Jerry Zhang Jian writes: > A monitor command is opaque to GDB: the stub can halt, resume, or > reset the target behind GDB's back, even if it later reports an > error, and the remote protocol has no way to tell GDB that happened. I don't find any of these example particularly clear. They all kind of hint towards a problem, but it would be nice to have at least one fully explained case. Take "halt". Do you mean the target is running in async mode, but GDB's "interrupt" command doesn't do what you need? Or does "halt" mean something different in this context? Or "resume". Why would GDB's normal resumption commands not be sufficient? If you resume the inferior via a monitor command that's going to leave GDB thinking the inferior is stopped when it's actually running, that's going to break you debug session, right? The "reset" example is by far the most obvious. The target is stopped an you want to restore it to some initial state. It's still stopped, but the register state has changed. > For example, "monitor reset halt" was leaving GDB reporting the > pre-reset $pc until a later step/continue forced a refetch. Do you mean "monitor reset halt" here? Even if you do due to some detail of your specific setup, is this really needed in the commit message? Wouldn't it be clearer just to pretend that the command was "monitor reset" as it feels (to me) like it is more obvious what this means. > > Invalidate the register cache after every monitor command via > SCOPE_EXIT, so it still runs on the error path. Scope it to the > inferior's own process_stratum_target, matching registers_changed_thread() > and the target_wait()/target_stop() lookup pattern elsewhere in this > file, rather than wiping every inferior's cache with registers_changed(). > Hold a strong reference to the target across the call in case it gets > unpushed/detached, the same idiom used in target_detach(). That all makes sense. > > Signed-off-by: Jerry Zhang Jian Please remove the 'Signed-off-by' tag, these are not used by GDB right now, but might be in the future. > --- > gdb/target.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/gdb/target.c b/gdb/target.c > index 5d937f3ae85..5c4684d81b5 100644 > --- a/gdb/target.c > +++ b/gdb/target.c > @@ -4262,6 +4262,18 @@ default_rcmd (struct target_ops *self, const char *command, > static void > do_monitor_command (const char *cmd, int from_tty) > { > + process_target_ops_ref proc_target_ref; > + if (process_stratum_target *proc_target > + = current_inferior ()->process_target ()) This treats a pointer as a bool. It would be clearer to just split the assignment out from the `if` and just have the `if` condition be `proc_target != nullptr`. Thanks, Andrew > + proc_target_ref = process_target_ops_ref::new_reference (proc_target); > + > + /* Monitor commands may change target state behind GDB's back. */ > + SCOPE_EXIT > + { > + if (proc_target_ref != nullptr) > + registers_changed_ptid (proc_target_ref.get (), minus_one_ptid); > + }; > + > target_rcmd (cmd, gdb_stdtarg); > } > > -- > 2.53.0