[RFC]: Pseudo-registers for GDB

[Michael Snyder <msnyder at cygnus dot com>]

This is a request for comment and discussion.

I want to add a general feature to GDB that will allow
a target architecture to define pseudo-registers
(things that are treated and accessed like registers, 
but perhaps not represented in actual hardware and not
fetched from the target like real registers).

Here are some examples of the applications I have in mind:

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.

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.

*********   IMPLEMENTATION   *************

The implementation that I have in mind is to add the 
pseudo-registers to the same data structures that presently
hold the register cache:
char *register_names[NUM_REGS];
char registers[REGISTER_BYTES];
signed char register_valid[NUM_REGS];

We would need a new constant to define where the real
(hardware) registers end, and the virtual registers
begin.  

Some routines (eg. target_fetch_registers) would then
traverse only the list of real hardware registers, while
others (register_name(), register_size(), etc) would 
apply to all (real and virtual).

The offsets of virtual registers in the cache would be
allowed to overlap those of real registers (or each other).
read_register_bytes etc. would have to be constrained from
copying the same region twice.

The distinction between real and virtual registers could
be confined to the functions "read_register" and "write_register"
(and their variants).  Most virtual registers would have to be
computed by target-specific code in the tdep modules.

All of this would have to be seamlessly integrated with 
both MULTI_ARCH and threads.

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?

				Michael Snyder