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

[Luis Machado]

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

Yes, vg is only available if feature org.gnu.gdb.aarch64.sve is available.