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~
