Re: [wip/cagney_regbuf-20020515-branch] Introduce regcache_move()

[Richard Earnshaw <rearnsha@arm.com>]

> There is a ``work around'' for this immediate problem.
> 
> I'm going to add a register_bytes() method to regcache that makes the [0 
> .. NUM_REGS + NUM_PSEUDO_REGS) contigious and returns an offset based on 
> that assumption.
> 
> write_register_bytes(), with the suggested change, will convert the 
> offset back to a regnum and call write_register_gen() with that.

Hmm, so each pseudo would allocate a unique address even though there was 
no real regbuf space for it; something like

  0         4               4*(n-1)   4*n       4*(n+1)   ...
  +---------+---------+     +---------+---------+---------+
  | Phys r0 | Phys r1 | ... | Phys rn | Pseu r0 | Pseu r1 |
  +---------+---------+     +---------+---------+---------+
  |     REGBUF          ...           |
  +--------------------     ----------+

Then each reg would have a unique address.  Provided we always call 
through the correct interfaces, and never use

 memcpy (grub_around...registers() + REGISTER_BYTE(PseudoN), ...)

then this would work.


> Rock warning: GDB uses the above to handle (with limited success) values 
> that cross two registers.  For instance a long long in two adjacent long 
> registers.  See value_from_register().

I've been told ARM's own C compiler can put long longs in non-adjacent 
register pairs.  At some point I will need to support that... it will 
probably mean being able to read from some ordered list of registers, or 
some such.

R.