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: cagney at redhat dot com
- Subject: Re: [PATCH]: New maintainer command "flushregs"
- From: Doug Evans <dje at transmeta dot com>
- Date: Sun, 10 Sep 2000 15:15:17 -0700
- cc: gdb-patches at sourceware dot cygnus dot com
Andrew Cagney wrote:
>
> Steven Johnson wrote:
>
> > The problem is, after a hardware Reset, all the registers have changed
> > but GDB does not know it. GDB Never looses connection to the target
> > because I am using a BDM Interface. So If I then try and re-set the
> > watchdog and debug registers using GDB, GDB thinks they have already
> > been set and refuses to change them.
>
> I'd think of this as a (design) bug in GDB. I think that there should
> be mechanism that allows the target/backend to notify GDB that the
> targets state has just been trashed.
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]?