Re: [PATCH] gdb: invalidate register cache after monitor commands

[Jerry Zhang Jian <jerry.zhangjian@sifive.com>]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

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 !=
nullptr.

Thanks,
Jerry

Tom Tromey <tom@tromey.com> 於 2026年8月13日週四 上午4:34寫道：

> >>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2666 bytes --]