Luis Machado <luis.mach...@linaro.org> writes:
> On 12/19/19 4:15 PM, Alex Bennée wrote:
>> Richard Henderson <richard.hender...@linaro.org> writes:
>>
>>> On 12/11/19 9:05 AM, Alex Bennée wrote:
>>>> +static struct TypeSize vec_lanes[] = {
>>>
>>> const.
>>>
>>>> + case 51:
>>>> + return gdb_get_reg64(buf, (cpu->env.vfp.zcr_el[1] & 0xf) + 1);
>>>
>>> You need to use sve_zcr_len_for_el to get the effective vq.
>>> Also, I thought vg == 2 * vq.
>>> > + case 51:
>>>> + {
>>>> + uint64_t val = *(uint64_t *) buf;
>>>> + cpu->env.vfp.zcr_el[1] = (val - 1) & 0xf;
>>>
>>> You cannot hard-code EL1 without ifdef CONFIG_USER_ONLY. If the effective
>>> vq
>>> decreases, you must call aarch64_sve_narrow_vq. You must call
>>> arm_rebuild_hflags.
>> I'm just going to drop vg (and therefor the ability to set it) from
>> the
>> regset. It was only meant to be an indicator and gdb doesn't actually
>> look to it to size it's output. The likely dynamic extension will just
>> re-transmit the whole XML when a change occurs.
>>
>
> I'd verify with GDB first if vg isn't actually required.
It works with my tests but perhaps we use our own namespaced XML rather
than the gdbstub XML.
> From looking at GDB's code, it does set vg as one of the register
> names, and this is regardless of any XML input. It does reference VG
> here and there in the code, even though it may not use it to size its
> output.
But this is all special casing for feature
name="org.gnu.gdb.aarch64.sve" right?
--
Alex Bennée
