This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH]: New maintainer command "flushregs"
Doug Evans wrote:
>
> 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?]
>
Yes, in some cases.
In my opinion, the problem is very small. It will only affect <1% of the GDB
population, and in those cases I think a manual over-ride is appropriate. for
example, the type of thing I would do if I wanted to use this command:
define reset-my-target
# 0xFFF00100 is my memory mapped registers location (32 bits wide)
# The most significant bit (D31) is tied to hard reset (Active High).
# Note: we don't need to clear it, because Hard reset feeds back on
# this register and causes it to clear automatically. Otherwise we
# would be permanently stuck in reset.
set {int}0xFFF00100,0x80000000
# And now, because GDB doesn't know that we have changed the world,
# Force it to forget anything it was caching.
flushregs
# If we were using the dcache, we would flush it here also.
# But im not, so i wont. (But you get the idea.)
end
then every time I wanted to reset my target:
(gdb) reset-my-target
works fine.
Steven Johnson