Re: Supplying regsets containing pseudoregisters

[Andrew Cagney <cagney@gnu.org>]

> I think I've run into a design problem in the interaction between the
> "supply" functions that move data from target-specific sources like
> ptrace and core files to the regcache, and the pseudoregister support.
> 
> The job of a regset's "supply" function is to (essentially) call
> regcache_raw_supply on the selected register from the regset, or on
> all the registers in the regset if the register number is -1.
> regcache_raw_supply drops the register's bits into the regcache.
> regcache_raw_supply only allows its callers to supply values of raw
> registers.

FYI, this was a design decision - the low code supplying / collecting 
registers only manipulates the raw register cache.  The old code, which 
tried to implement pseudo-registers in the supply / collect code, didn't 
enforce this, and the result was a mess.

> But sometimes the values in a regset correspond to pseudoregisters.
> For example, on the PowerPC E500, the general-purpose registers are 64
> bits wide, but the E500 doesn't implement the normal PPC 64-bit
> integer instructions; the only instructions which access the upper 32
> bits are special SIMD vector instructions.  GDB represents E500 gprs
> as pseudoregisters stored in the lower halves of the ev0--ev31
> registers, which are raw registers each 64 bits long.  On E500 Linux,
> a gregset_t (as found in a core file, or as handled by libthread_db)
> contains the values of the 32-bit GPRs, not the 64-bit EV registers.
> So the 'supply' function for such a regset has pseudoregister values,
> but because of regcache_raw_supply's interface, it needs to supply raw
> register values.

It sounds like the regcache layout needs to be changed.  I'd break the 
raw EV registers down into hi:lo pairs so that each part can be supplied 
separatly - this appears to more closely reflect the underlying 
implementation.

Andrew