Re: [PATCH v3 12/20] target/arm: generate xml description of our SVE registers

[Alan Hayward]

> On 20 Dec 2019, at 13:18, Luis Machado <address@hidden> wrote:
> 
> On 12/20/19 10:14 AM, Alex Bennée wrote:
>> Luis Machado <address@hidden> writes:
>>> On 12/19/19 4:15 PM, Alex Bennée wrote:
>>>> Richard Henderson <address@hidden> 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.


>>> 
>>> 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.

Yeah, if your gdb stub is providing an XML description, then essentially it can
provide whatever registers it wants to in the XML, and most stuff will just 
work.
When using a gdb stub, nothing (as far as I can recall) in GDB is relying on VG 
existing
or using its value.


>>> 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.

When using GDB a real SVE Linux box without a stub/gdbserver, then:

*Before doing anything with the target description (for example after every 
breakpoint),
GDB always asks the target (ie the GDB aarch64 port) for the XML description 
again. This
function re-reads the vector length; if the length has changed then it 
constructs a
new XML description and forces the registers to be re-read.

*When writing the registers back, the aarch64 target checks the VG value and if 
changed
writes that first. This can fail (with an error printed to the output). The 
rest of the
registers are then scaled and written according to the new size. There is no 
need to
change the xml at this stage as it’ll be done the next time GDB uses the 
description.

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.


>> 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.



Alan.