This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH]: New maintainer command "flushregs"
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.
>
I agree with you, this would be ideal. It could be in the Stubs response
to "Stub"
commands (that is 'qRcmd') Unfortunately, the way it is defined, it is
either 'OK',
or 'E'NN, or a Hex Encoded Output string. This doesn't give much
latitude for
change. Maybe we could extend the general 'OK' Response to something
like:
'OK' means OK as it does now, but 'OK:flag,flag,flag' tells GDB The
operation was OK
but here are some things you should know.
Eg,
'OK:r' - Means OK, but one or more registers may have changed state.
This would then
enable pretty much any command in the remote protocol to tell GDB about
state changes.
Other state changes could be things like memory cache changes ('m'
maybe) and the like.
This also doesn't help in the situation where there are registers that
are different
every time you read them, or need to be written with the same value
multiple times.
I Think there are places where both mechanism types are warranted.
Without changing the Remote protocol, I would wrap a Stub Command that
corrupted the
registers in a GDB Command, like:
define mycommand
remote myremotecommand
maint flush registers
end
This way I have control, and I don't need to change the stub. (Which may
be in ROM).
> > 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().
>
Thanks for the info.
Steven.