qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 12/14] target/arm: generate xml description of our SVE reg


From: Richard Henderson
Subject: Re: [PATCH v2 12/14] target/arm: generate xml description of our SVE registers
Date: Mon, 2 Dec 2019 10:44:49 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1

On 11/30/19 8:46 AM, Alex Bennée wrote:
> +struct TypeSize {
> +    const char *gdb_type;
> +    int  size;
> +    const char sz, suffix;
> +};
> +
> +static struct TypeSize vec_lanes[] = {

static const.

> +    for (bits = 128; bits >= 8; bits = bits/2) {

Mind the spacing in the binary /, or bits /= 2.

> +#ifdef TARGET_AARCH64
> +static int arm_gdb_get_svereg(CPUARMState *env, GByteArray *buf, int reg)
> +{
> +    ARMCPU *cpu = env_archcpu(env);
> +    DynamicGDBXMLInfo *info = &cpu->dyn_svereg_xml;
> +
> +    /* The first 32 registers are the zregs */
> +    if (reg < 32) {
> +        int vq, len = 0;
> +        for (vq = 0; vq < cpu->sve_max_vq; vq++) {
> +            len += gdb_get_reg128(buf,
> +                                  env->vfp.zregs[reg].d[vq * 2 + 1],
> +                                  env->vfp.zregs[reg].d[vq * 2]);
> +        }
> +        return len;

This is tricky.  The "standard" ordering of sve vectors is a stream of bytes,
in little-endian ordering.  This is how the hardware handles things, even in
big-endian mode.

I'm not sure how gdb is set up to handle this.  Probably it
doesn't matter for now, since almost no one uses BE, and can
fixed later if needs be.

> +    case 2 ... 19:
> +    {
> +        int preg = reg - info->data.sve.fpsr_pos - 2;
> +        int vq, len = 0;
> +        for (vq = 0; vq < cpu->sve_max_vq; vq = vq + 4) {
> +            len += gdb_get_reg64(buf, env->vfp.pregs[preg].p[vq / 4]);
> +        }
> +        return len;
> +    }

The byte ordering of the predicate registers is similar.

This output does not appear to work for vq % 4 != 0.  The vqp type is defined
as a vector of uint16, so you'd need to output in units of reg16, extracted
from the uint64_t as

  extract64(env->vfp.pregs[preg].p[vq / 4], vq % 4 * 16, 16);


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]