This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH]: New maintainer command "flushregs"
- To: Steven Johnson <sbjohnson at ozemail dot com dot au>
- Subject: Re: [PATCH]: New maintainer command "flushregs"
- From: Doug Evans <dje at transmeta dot com>
- Date: Sun, 10 Sep 2000 18:36:16 -0700 (PDT)
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <200009102215.PAA03411@casey.transmeta.com><39BC2A72.8361A30C@ozemail.com.au>
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.]