Re: [PATCH v2 12/13] M68K Linux: Define regset structures.

[Andreas Arnez <arnez@linux.vnet.ibm.com>]

On Tue, Jul 15 2014, Ulrich Weigand wrote:

> Andreas Arnez wrote:
>
>> +static const struct regcache_map_entry m68k_linux_fpregmap[] =
>> +  {
>> +    { 8, M68K_FP0_REGNUM },	/* fp0 ... fp7 */
>> +    { 1, M68K_FPC_REGNUM },
>> +    { 1, M68K_FPS_REGNUM },
>> +    { 1, M68K_FPI_REGNUM },
>> +    { 0 }
>> +  };
>> +
>> +#define M68K_LINUX_FPREGS_SIZE (27 * 4)
>
> Hmm.  Not sure what happens on m68k_coldfire_flavour, where the GDB
> FP registers have builtin_double type (i.e. 8 instead of 12 bytes).
> On the other hand, the current m68klinux-nat.c supply_fpregset
> doesn't make any provisions for that case either ... is coldfire
> supported on Linux at all?

At least in the Linux kernel source, e.g. in arch/m68k/Kconfig.cpu, it
looks to be supported.  And it seems that the registers are still
assigned to 12-byte slots, even if they fit in 8 bytes.  So,
supply_fpregset may work correctly on ColdFire, but then the new code
doesn't.

Maybe it helps to add a "register slot size" field to each regmap entry?
So we'd write:

static const struct regcache_map_entry m68k_linux_fpregmap[] =
  {
    { 8, M68K_FP0_REGNUM, 12 },	/* fp0 ... fp7 */
    { 1, M68K_FPC_REGNUM, 4 },
    { 1, M68K_FPS_REGNUM, 4 },
    { 1, M68K_FPI_REGNUM, 4 },
    { 0 }
  };

This approach would also make the offsets and total size more obvious --
in this case 8 * 12 + 3 * 4.  On the downside, it doesn't allow re-using
the same map for different word sizes.  Perhaps we could additionally
permit the 'size' field to be zero and then use the register size
instead.  Thoughts?