[PATCH] Support large registers in regcache transfer_regset
Alan Hayward
Alan.Hayward@arm.com
Tue Jun 19 15:46:00 GMT 2018
> 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.
More information about the Gdb-patches
mailing list