This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Steven Johnson writes:
 > 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.

Thanks.  This is an example that clears things up for me.

Still, I'm not quite sure a protocol enhancement will sufficiently help.
[would the stub now and then also have to resort to guessing?]

Also, if you did flush the register cache everytime there was a remote
possibility something had change, the register cache would still be a win
[though less so of course.  Question: how much less so?]
A half-way solution would be to only flush if memory was written (and
not flush when reading memory).  I don't know enough about register
cache usage to say how much this would slow things down.
Maybe that, coupled with the command line option to flush the cache would
be sufficient?  [Though, I like the idea of being able to specify which
registers get cached and how.]

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]