[RFA] regcache.c (register_fetched) + related changes
Thu Mar 1 10:34:00 GMT 2001
Date: Wed, 28 Feb 2001 18:14:29 -0500
From: Andrew Cagney <email@example.com>
David Taylor wrote:
> From: Andrew Cagney <firstname.lastname@example.org>
> Date: Tue, 27 Feb 2001 20:38:30 -0500
> David Taylor wrote:
> > I propose that we:
> > . add register_fetched
> 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?
> Supply register does more than register_fetched; register_fetched only
> affects register_valid -- the register must have been supplied via
> some other method.
Yes, that is what I mean by their functionality overlapping. There is
much legacy code of the form:
blat the registers array
set register_valid to 1
But, there also exists code that does not directly blat the
registers array, but nonetheless still needs to mark one or more
registers as cached -- i.e. has to set one or more register_valid
locations to 1!
The accepted ``correct fix'' for that code is to replace it with
supply_register(). It is just an unfortunate reality that no one has
the time to do the work. I have a feeling that, right now GDB is
deleting this code faster than it is being fixed!
The STORE_PSEUDO_REGISTER routines do not get the register contents as
an argument. But they potentially need to set and clear various
To clear a location (i.e., mark it as "invalid") they can use the
existing register_changed function; but there is currently no
functional interface for them to set (i.e., mark as "cached" or
"valid") a location.
That is the point of my proposed function:
register_fetched (int regnum)
set_register_cached (regnum, 1);
And the rest of the changes (excluding the one line declaration in a
header file) are just to modify existing targets to use a functional
interface rather than referencing register_valid directly.
Given that reailty, if this code is going to be changed, I would prefer
it changed in a way that made it very clear that this is not the correct
way to do things. Taking a lead from DEPRECATED_SERIAL_FD I think those
blocks can be converted to something like:
I wasn't changing the accesses to the registers array. Nor do I
currently have the time to spend to make such a change just to get the
above one line function accepted. I've already spent more time on
this than I should have.
I guess for now I'll just have to say register_valid[...] = 1; in my
tdep file. Maybe when the revolution comes... but until then... Very
*deprecated_register_buffer(...) = ...;
> 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.
Yes. My suggestion, hinted at in the last e-mail, would be to combine
the two disjoint operations:
into an atomic cache transaction:
> 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:
> 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.
I agree, eliminating register_valid and registers are important
goals. The thing to be wary of is a change that just substitutes
something like registers and register_valid without actually
improving the overall quality of the code. I think it is important to
ensure that any proposed change to GDB moves its overall code quality
forward (and not just sideways).
Grubbing around for other cases.
Grubbing through the code, the other case where register_valid is
being blatted is:
/* These (for the most part) are pseudo registers and are obtained
by other means. Those that aren't are already handled by the
code above. */
for (regi = IA64_GR32_REGNUM; regi <= IA64_GR127_REGNUM; regi++)
register_valid[regi] = 1;
for (regi = IA64_PR0_REGNUM; regi <= IA64_PR63_REGNUM; regi++)
register_valid[regi] = 1;
for (regi = IA64_VFP_REGNUM; regi <= NUM_REGS; regi++)
register_valid[regi] = 1;
I'm guessing that code somewhere is looking at register_valid to
decide if a pseudo is available. The actual value (hopefully) being
supplied by the pseudo-register method.
Unless a pseudo shares nothing with any real register, with the
current interfaces a tdep file should *NEVER* allow register_valid to
be 1 for that pseudo register. Otherwise, when something updates one
of the contributing registers, the pseudo will still be marked as
valid when it might not be valid.
While that particular hack could eventually be fixed in other ways
(short term by having the ``register_cached()'' method ask gdbarch if a
pseudo is valid; and long term by having the register_valid() method
bound to a frame and always asking gdbarch if i is valid) that ain't
going to solve the hear and now.
Given that, I think this case (pseudo) is different/separate to the
legacy code case, I don't think it makes sense to use an interface like
deprecated_register_valid(). Instead, I think a separate:
Are you proposing this as setting the location? Or are you proposing
this as a query function? I would welcome a such a query function.
If you are proposing a "set" function, then until other changes are
made (namely, changes that allow the implementor to keep the pseudo
bits current), I would object to encouraging a false sense of security
Interface should be available. I think this also helps to differentiate
the more recent pseudo from legacy code.
The other case I'm aware of, is with registers and core-gdb poking
around in that instead of using the read/write register functions. I
think, there, the deprecated_register_buffer() method would be fine.
That code should be using the read_register*() functions and not pokeing
around in that buffer.
> 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.
> What change is this that you are referring to? The message with subject
> [rfc] Re-merged regcache.h patch
I also mentioned:
o The changes adding:
+ #define REGISTER_CACHE_UNAVAILABLE (1)
+ #define REGISTER_CACHE_VALID (0)
+ #define REGISTER_CACHE_INVALID (-1)
(or enum equivalents) were stripped out.
These changes badly clashed with Davids
proposed register_*() change so, I'll
leave them for later.
Which I saw; but, they aren't part of the patch. (And either the
un-included part changes the meanings of the register_valid slots, or
the above defines are wrong.)
I was actually wrong here. The changes were only in my local sandpit
and not in the original patch.
> +/* Character array containing the current state of each register
> + (unavailable<0, valid=0, invalid>0). */
See inferior.h:register_valid. I'll fix the comment. Thanks for
Yes, the comment in inferior.h is wrong.
I didn't delete the declaration as part of my proposed patch because,
as I said, there were still three locations (spread between two files)
that still referenced register_valid.
Any way, to summarize, I'm proposing:
register_valid = 1;
where this I/F would only work on raw registers.
registers_valid[pseudo] = 1;
where the register must be a pseudo.
... = registers;
... = depreciated_register_buffer();
I think this is a reasonable balance between the immediate desire of
eliminate the globals registers_valid and registers and the long
term objective of eliminating code that blats arbitrary bytes in the
And, as I said, there are times when you need to get the effect of
register_valid[regno] = 1 when you have not blatted the registers
array. The question, in my mind, is whether to continue to directly
set it or to instead have a functional interface. I would prefer that
there be a functional interface -- then it would be possible to make
register_valid be static (i.e., private to the regcache.c file) [and
to eventually make it go away].
More information about the Gdb-patches