Re: [PATCH]: New maintainer command "flushregs"

[Steven Johnson <sbjohnson at ozemail dot com dot au>]

Doug Evans wrote:

> 
> There is registers_changed(), which remote-sim.c calls
> in simulator_command() "in case the simulator command does something funny".
> For my own education, why isn't that sufficient here?  i.e. Why can't/shouldn't
> all commands that may cause arbitrary or unknown changes to the target
> call registers_changed() [or it's equivalent that DTRT]?

You could call it, but the problem I think is with commands executed by the
stub that are just passed to it verbatim from GDB. GDB doesn't know what the
target state is after the command. Sometimes it's OK, sometimes it's changed. 

I Think a better approach is to make the remote protocol return a status that
indicates a changed target state that requires the caches to be flushed. Then
it is the stubs problem. GDB shouldn't have to "guess" when the state changes.
There will invariably be cases when it guesses wrong. 

The other way is to have a command that can do it at the gdb end, that way if a
stub doesn't do it, or there are other reasons the state changes, it can be
forced by the user.

For example, setting an IO Line in a memory mapped register location that is
connected to hard reset, and the stub is not resident on the debugged target.

The stub doesn't know the target has been reset, it just performed a memory
write. 

GDB doesn't know the target has been reset, it also just performed a memory
write.

Only the user of gdb that forced this knows it happened. That user should then
be responsible for flushing the caches, otherwise they get bad results.
Automatic is good and in 99% of the cases perfect. But in a situation like this
where it can fail, having a manual override makes it 100%.

Why do I care, because currently my target, the way I do my stub, and the
things I want to do with them put me in that 1%.

The other alternative to be 100% is to call registers_changed() after every
remote command. But if you do this then why bother register caching in the
first place.

Steven.