Re: [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (2/4)

[Pedro Alves <palves at redhat dot com>]

On 05/22/2017 05:05 PM, Alan Hayward wrote:

>      {
>        enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> -      gdb_byte buf[MAX_REGISTER_SIZE];
>        LONGEST val;
> 
> -      val = extract_signed_integer ((const gdb_byte *) addr, len, byte_order);
> -      store_signed_integer (buf, register_size (gdbarch, regnum), byte_order,
> -			    val);
> -      regcache_raw_supply (regcache, regnum, buf);
> +      val = extract_integer<LONGEST> ((const gdb_byte *) addr, len, byte_order);
> +      regcache->raw_supply (regnum, val);
>      }
>  }
> 

>    else
>      {
>        enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> -      gdb_byte buf[MAX_REGISTER_SIZE];
> -      LONGEST val;
> -
> -      regcache_raw_collect (regcache, regnum, buf);
> -      val = extract_signed_integer (buf, register_size (gdbarch, regnum),
> -				    byte_order);
> -      store_signed_integer ((gdb_byte *) addr, len, byte_order, val);
> +      LONGEST val = regcache->raw_collect<LONGEST> (regnum);
> +      store_integer ((gdb_byte *) addr, len, byte_order, val);

I wonder whether we can get rid of the LONGEST / host integer
middleman and simplify things while at it.  For instance, what if we
had a version of raw_collect that took the destination buffer length
as parameter:

      regcache->raw_collect_integer (regnum, (gdb_byte *) addr, len);

that would copy bytes over into addr, and if the register is
narrower than LEN, then it'd insert the necessary
leading zeros (or 0xFFs if signed extension necessary),
and if the registers is wider than LEN, then it'd skip
copying enough significant bytes so that LEN fits.

Likewise for regcache->raw_supply.


> --- a/gdb/regcache.h
> +++ b/gdb/regcache.h
> @@ -21,6 +21,7 @@
>  #define REGCACHE_H
> 
>  #include "common-regcache.h"
> +#include "defs.h"

Headers should not include defs.h.  Is there some .c file that
misses including defs.h first thing?

Thanks,
Pedro Alves