Supplying regsets containing pseudoregisters

[Jim Blandy <jimb@redhat.com>]

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.  So there's an assumption that regset contains raw register
values.

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.

The supply function can certainly do the cooked->raw form conversion
itself, but that would be a duplication of the code in the existing
pseudo_register_write function.  Unfortunately, pseudo_register_write
functions are defined work by writing to the underlying raw registers
with regcache_raw_write and friends, which ends up calling
target_store_registers, which isn't the sort of behavior a supply
function wants.

Ideally, the definition raw/pseudo relationship could be localized to
one set of functions.  But it looks to me as if regset supply
functions need to implement it too.

I can certainly break out the PPC pseudo/raw correspondence into
functions that take the raw read/write functions as parameters, and
pass regcache_raw_supply when I'm supplying a regcache, and
regcache_raw_write when I'm writing a pseudoregister.  That would keep
the correspondence localized to one set of functions, but it feels to
me like begging the question: there's no intrinsic reason to assume
that what GDB developers decide to call raw registers will always
match what OS developers decide to put in gregset_t and fpregset_t.

What's the thinking on this?