Re: [RFC]: Pseudo-registers for GDB

[Andrew Cagney <ac131313 at cygnus dot com>]

[I suspect that I hit the wrong button half way though composing this]

Michael Snyder wrote:

> As a first step, I propose to move the register cache from
> its present ill-concieved location in findvar.c into its own
> module (tentatively named regcache.c), and to make it a true
> data object (with access functions to replace the direct
> access that some modules now make).  After that, changes to
> the data structure should have minimal impact on the rest of
> GDB.
> 
> Comments?

Yes please!

Well the first step has to be a good thing (tm).  Right now
we've no idea how various targets are using (and abusing)
register_bytes[] so placing it under some sort of control means, as you
point out, it can be re-implemented cleanly.

Interestingly,  this is the same first step that would need to be taken
if there is to be a per-thread register cache.  So definitly a
good move!

> 1) real vs. virtual frame pointer.
> Many architectures have a dedicated frame pointer register,
> but in some circumstances (eg. "frameless" leaf functions)
> there is a virtual frame pointer that is not kept in a
> register at all.  In that case the value of the "frame location"
> is different from the value of the '$fp' register.
> 
> At present, GDB will report one value if you say
> "info register $fp", and a different value if you say
> "print $fp".
> 
> With pseudo-registers, we could define a virtual FP register
> in addition to the hardware FP register.  The virtual one
> would be computed rather than fetched from the target machine.
> The confusion between the FP register and the virtual frame
> pointer would be eliminated.

In the case of the virtual-fp, since it really has nothing to do with
the target, would it be better to keep it separate from *-tdep.c and
hence regcache.[ch]?

I suspect, looking at this pragmatically, that it is far more important
to get the regcache.[hc] up and running than trying to also resolve
this.

> 2) register pairs.
> Sometimes registers can be addressed either separately or
> joined / concatenated together.  For instance, MIPS has some
> number of single-precision floating point registers, which can
> be paired into half that number of double precision regs.
> 
> We could treat the single-precision regs as real hardware
> regs, and fetch them from the target as usual.  The 
> combined (double precision) regs would be pseudo-regs; 
> addressable by name, but not needing to be fetched once
> the single-precision ones are fetched or stored.  They
> would share the same storage in the register cache, even
> as they share the same storage on the target machine.
> 
> 3) vector registers.
> Another example of shared storage.  Some architectures can
> have vector co-processors, where a largeish number of 
> register 'elements' are joined into one array of registers.
> We could store the elements in the cache as discretely 
> addressable registers, and also define a single vector
> register to address them all at once.  With such large
> registers, the disadvantage of fetching the values twice
> are easy to see.

A slightly more technical question.  When GDB displays register
information for the non-inner most frame, it uses a union of information
obtained from both a ``struct frame'' and the register buffer.  

I guess the strategy here is to first get regcache.[ch] working and
supporting virtual registers and then, later update the frame code so
that it can handle things the same way.  Assuming that is the stragegy
then it is definitly a good move.

	Andrew