Alan Hayward <alan.hayw...@arm.com> writes:
>> On 20 Dec 2019, at 13:18, Luis Machado <luis.mach...@linaro.org> wrote:
>>
>> On 12/20/19 10:14 AM, Alex Bennée wrote:
>>> 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.
>>>>>
>
> [...rebooting self after festive break]
>
> Yes, when using a gdb stub, changes to the VG value should be silently
> ignored by the
> stub.
> In addition, if the vector length on the system does magically change whilst
> the program
> is running, then the stub should continue to use the register sizes for the
> originally
> transmitted XML, truncating/extending the register values as required.
>
> Why? Because once the stub has sent the XML description to GDB on program
> start, then GDB
> assumes the XML description will never change. GDB will error if sent packets
> with different
> register lengths.
Ack. The test "test-sve-ioctl.py" covers this and works as expected.
<snip>
>
> When using GDB a real SVE Linux box without a stub/gdbserver, then:
>
<snip>
>
> Blindly enabling the above when using a stub results in in GDB *constantly*
> asking the
> stub for a new XML description, spamming the pipe, so this needs something
> more nuanced.
>
> I plan on sending Luis my ideas I had for VG changing when using a
> stub.
Is this going to be a more general solution because I'm sure there are
other cases where the XML description is out of date. A big one is
execution modes (thumb/32/64 bit) and I think x86 runs into similar
problems with it's various mode changes in early boot-up.
For now I'll just let qemu provide it's own xml without vg shenanigans.
>>> But this is all special casing for feature
>>> name="org.gnu.gdb.aarch64.sve" right?
>>
>> Yes, vg is only available if feature org.gnu.gdb.aarch64.sve is available.
>
> Nod.
Thanks and hi ;-)
--
Alex Bennée
