This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] regcache.c (register_fetched) + related changes
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFA] regcache.c (register_fetched) + related changes
- From: David Taylor <taylor at cygnus dot com>
- Date: Wed, 28 Feb 2001 16:13:58 -0500
- cc: gdb-patches at sources dot redhat dot com
From: Andrew Cagney <ac131313@cygnus.com>
Date: Tue, 27 Feb 2001 20:38:30 -0500
David Taylor wrote:
> I propose that we:
>
> . add register_fetched
David,
The functionality of register_fetched() overlaps with
set_register_cached() and supply_register(). Rather than add a
redundant method, could an existing interface be used or the current
interfaces rationalized slightly?
Andrew,
Supply register does more than register_fetched; register_fetched only
affects register_valid -- the register must have been supplied via
some other method.
set_register_cached is -- with one exception -- only used within
regcache.c. The one exception is remote.c (remote_fetch_registers).
I feel that a function should be created (register_unavailable?) and
the call in remote.c to set_register_cached replaced with that call.
Then set_register_cached should be made static.
To call set_register_cached, you have to know what the meanings are of
the various possible values of register_valid. This is knowledge that
shouldn't really exist outside of regcache.c.
Keep in mind that the long term goal is to tighten regcache's interface
signficantly. That is, eliminate register_valid[], registers[] and
possibly even set_register_cached() replacing them with a small set of
functions such as:
supply_register()
supply_unavailable_register()
If you are thinking of proposing further changes then you may want to
keep that in mind.
My change advances the goal of eliminating register_valid! It reduces
significantly the number of files that even know that register_valid
exists! Outside of regcache.c, only two files would reference it (for
a total of three references). Those two files could also have their
references to it removed with a little bit more work.
With regard to regcache.h, yes the two clash. It both moves code around
and changes the set_register_cached() interface. If anything regcache.h
makes life easier because it is finally clear what the regcache
interfaces really are.
Andrew
What change is this that you are referring to? The message with subject
[rfc] Re-merged regcache.h patch
that you posted after the above message? I assume not, but if so...
. It does not move around code within regcache.c. It adds a comment
to regcache.c. I don't see that as a conflict with my patch.
. Yes, it adds a new header file regcache.h. A header file that is
long overdue. But, that does not affect the bulk of my patch. It
means that my one line change to gdbcore.h becomes instead a one
line change to regcache.h. Not a big deal -- I can change this
easily enough.
. The posted patch does not change the set_register_cached interface.
It does add a comment concerning the interface that conflicts with
reality:
+/* Character array containing the current state of each register
+ (unavailable<0, valid=0, invalid>0). */
but that is a problem with that patch, not with mine.
[Current reality is: unavailable<0, invalid=0, valid>0.]
David