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

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

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