Supplying regsets containing pseudoregisters

Supplying regsets containing pseudoregisters

[Jim Blandy]

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?

Re: Supplying regsets containing pseudoregisters

[Andrew Cagney]

> 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

Re: Supplying regsets containing pseudoregisters

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:
> 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.

Okay.  This is what I'd started doing thinking of it as a workaround,
so it works for me.

Re: Supplying regsets containing pseudoregisters

[Jim Blandy]

Jim Blandy <jimb@redhat.com> writes:

> Andrew Cagney <cagney@gnu.org> writes:
> > 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.
> 
> Okay.  This is what I'd started doing thinking of it as a workaround,
> so it works for me.

Actually, maybe not.

The sim provides access to the GPRs as full 64-bit values.  It calls
sim_fetch_register, gets 64 bits, and then calls supply_register on
the full 64 bits.

But core files and libthread_db operate on gregset_t values, which
contain only the lower 32 bits of the GPRs.  The regset 'supply'
functions want to call regcache_raw_supply on only the lower halves.

So does gdbsim_fetch_register need to be tweaked somehow?  How would
it know how to distribute the 64-bit value across high/low pairs?

Do I need to use separate regcache layouts for sim and native?  How
would I even do that?

Re: Supplying regsets containing pseudoregisters

[Andrew Cagney]

> The sim provides access to the GPRs as full 64-bit values.  It calls
> sim_fetch_register, gets 64 bits, and then calls supply_register on
> the full 64 bits.

You'll need to update that interface so that it is consistent with the 
gregset code.

Andrew