This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH]: New maintainer command "flushregs"
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [PATCH]: New maintainer command "flushregs"
- From: Michael Snyder <msnyder at redhat dot com>
- Date: Mon, 04 Sep 2000 13:00:31 -0700
- CC: Steven Johnson <sbjohnson at ozemail dot com dot au>, gdb-patches at sourceware dot cygnus dot com
- Organization: Red Hat, Inc.
- References: <39AFEEC4.37C9@redhat.com> <39B0F20E.F5670288@ozemail.com.au> <39B395A4.FD5730BD@cygnus.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.
> > Also, do you know how one goes about turning $regname into a register
> > number? I haven't found this yet?
> grep for REGISTER_NAME. GDB does a linear search through the
> REGISTER_NAME table - see parse.c:target_map_name_to_register().
... which we ought to change into an access function, to
hide the underlying data structure...