Re: [PATCH] Support large registers in regcache transfer_regset

[Alan Hayward <Alan.Hayward@arm.com>]

> On 19 Jun 2018, at 15:52, Simon Marchi <simark@simark.ca> wrote:
> 
> On 2018-06-19 07:27, Alan Hayward wrote:
>>>> +/* See regcache.h.  */
>>>> +
>>>> +void
>>>> +reg_buffer::raw_collect_part (int regnum, int offset, int len, void *in) const
>>>> +{
>>>> +  struct gdbarch *gdbarch = arch ();
>>>> +  gdb_byte *reg = (gdb_byte *) alloca (register_size (gdbarch, regnum));
>>>> +
>>>> +  gdb_assert (in != NULL);
>>>> +  gdb_assert (offset >= 0 && offset <= m_descr->sizeof_register[regnum]);
>>>> +  gdb_assert (len >= 0 && offset + len <= m_descr->sizeof_register[regnum]);
>>> The "&& offset <= m_descr->sizeof_register[regnum]" is redundant, given the
>>> following line.  Other than mimicking raw_read_part, is there a reason why
>>> these are signed integers?  Having them unsigned would avoid having to assert
>>> they are >= 0.
>> Looking at regcache, int is used for regnum throughout. I’d rather not have a
>> mismatch, and wouldn’t want to update everything else either (at least not
>> in this patch). In addition, if this code is going to now call down to
>> raw_collect/raw_supply, they should match.
> 
> Sorry, I was talking about len and offset, not regnum.
> 
> Simon

Ah, ok. If doing that, then it’d make sense to update regcache_map_entry to use
unsigned ints for count and size.

struct regcache_map_entry
{
  int count;
  int regno;
  int size;
};

At that point it probably makes sense to repost the patch as v2 in smaller pieces?


Alan.