From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50356 invoked by alias); 12 Jun 2019 13:18:35 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 50342 invoked by uid 89); 12 Jun 2019 13:18:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Jun 2019 13:18:33 +0000 Received: by mail-wr1-f65.google.com with SMTP id n9so16932886wru.0 for ; Wed, 12 Jun 2019 06:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=1fX4EtJtvN4zU4wq5BVv4qlv5K+6diDbCy8hF8AgIZE=; b=HQUQbZAFv8L8V+qh817uj8P7sjG5MrjyhVL6L3Glgc2NWMxo7h3cXWj/kykhA44P2W 6Z9akG4az+F0zxzveJGXwLqRqdjoFHZk5efmr6ZOpybhUvAUR8zVZQDJMpWrWYhwwL+p G5/4h8h4rIUHApMQgb9V3VhPp+AkesvZz8kQC6tB5Ezq5Esx/ujJqSpBLTmEQcNvOcjo LhpGbChOScDg0XryNdKs/o1WmO9UU5FP/oBXlnfep+nH4vXGpypf8l56GYbSJjNBi2vL 98wXiuu+JYk5R2gt2x42ZFDSYJOLxnopvCgw+6hR1Ffz3hZ63P1BeZeRMWduVGVvzWTW iKgQ== Return-Path: Received: from zen.linaroharston ([81.128.185.34]) by smtp.gmail.com with ESMTPSA id t14sm15474792wrr.33.2019.06.12.06.18.30 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 12 Jun 2019 06:18:30 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id C2AAA1FF87; Wed, 12 Jun 2019 14:18:29 +0100 (BST) References: <1559839495-22315-1-git-send-email-Dave.Martin@arm.com> <20190607093858.GA21378@fuggles.cambridge.arm.com> <20190607154832.GH28398@e103592.cambridge.arm.com> <207E140D-AC57-4B0D-B838-94B92BE2B0A0@arm.com> <87v9xbdr3o.fsf@zen.linaroharston> <20190612124712.GR28398@e103592.cambridge.arm.com> User-agent: mu4e 1.3.2; emacs 26.1 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Dave Martin Cc: Alan Hayward , Peter Maydell , Catalin Marinas , Will Deacon , Zhang Lei , Julien Grall , "gdb\@sourceware.org" , nd , "linux-arm-kernel\@lists.infradead.org" , "richard.henderson\@linaro.org" Subject: Re: [PATCH 0/2] arm64/sve: Fix mutating register endianness on big-endian In-reply-to: <20190612124712.GR28398@e103592.cambridge.arm.com> Date: Wed, 12 Jun 2019 13:18:00 -0000 Message-ID: <87sgsfdjru.fsf@zen.linaroharston> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00021.txt.bz2 Dave Martin writes: > On Wed, Jun 12, 2019 at 11:40:11AM +0100, Alex Benn=C3=A9e wrote: >> >> Alan Hayward writes: >> >> >> On 7 Jun 2019, at 16:48, Dave Martin wrote: >> >> >> >> On Fri, Jun 07, 2019 at 10:38:58AM +0100, Will Deacon wrote: >> >>> On Thu, Jun 06, 2019 at 05:44:53PM +0100, Dave Martin wrote: >> >>>> By inspection while debugging something else, I noticed that the by= te >> >>>> order of FPSIMD V-register stores and SVE Z-register stores is not = the >> >>>> same when running on big-endian. >> >>>> >> >>>> This is not properly taken into account when moving between the FPS= IMD >> >>>> and SVE register views inside the kernel, resulting in the bytes of= a >> >>>> V-register getting spontaneously reversed in some situations, from >> >>>> userspace's point of view. The signal frame and ptrace interface a= re >> >>>> also affected. The KVM ABI forbids mixing the two views and so sho= uld >> >>>> not be affected. >> >>> >> >>> Wouldn't this be easy enough to test? >> >> >> >> So, gdb works OK on big-endian but weird stuff happening on both with >> >> and without the fix. >> >> >> >> There are places in the gdb code itself where it is likely missing >> >> endianness conversions, but I need to follow up with the gdb folks to >> >> clarify whether my patch is missing something=E2=80=A6 >> > >> > (I added the SVE support for GDB). >> > >> > I=E2=80=99ve tried these changes out myself using GDB. >> > With your changes everything looks good, apart from: >> > * GDB gets it wrong when the ptrace sve structure contains a fpsimd. >> > * I need to do some testing around sigcontexts, but again I think GDB >> > will need a slight change. >> > I=E2=80=99ll get some patches together for GDB. >> >> Where is the latest state of SVE support for GDB? I really should check >> the QEMU gdbstub does the correct things for SVE registers but I was >> waiting for upstream gdb support. > > Does this issue need looking at for the QEMU userspace emulation too? Hmm I think we are OK. For the SVE frame itself we explicitly store in LE order: static void target_setup_sve_record(struct target_sve_context *sve, CPUARMState *env, int vq, int size) { int i, j; __put_user(TARGET_SVE_MAGIC, &sve->head.magic); __put_user(size, &sve->head.size); __put_user(vq * TARGET_SVE_VQ_BYTES, &sve->vl); /* Note that SVE regs are stored as a byte stream, with each byte ele= ment * at a subsequent address. This corresponds to a little-endian store * of our 64-bit hunks. */ for (i =3D 0; i < 32; ++i) { uint64_t *z =3D (void *)sve + TARGET_SVE_SIG_ZREG_OFFSET(vq, i); for (j =3D 0; j < vq * 2; ++j) { __put_user_e(env->vfp.zregs[i].d[j], z + j, le); } } for (i =3D 0; i <=3D 16; ++i) { uint16_t *p =3D (void *)sve + TARGET_SVE_SIG_PREG_OFFSET(vq, i); for (j =3D 0; j < vq; ++j) { uint64_t r =3D env->vfp.pregs[i].p[j >> 2]; __put_user_e(r >> ((j & 3) * 16), p + j, le); } } } For the aliased fpsimd registers we store in the target endian format: static void target_setup_fpsimd_record(struct target_fpsimd_context *fpsi= md, CPUARMState *env) { int i; __put_user(TARGET_FPSIMD_MAGIC, &fpsimd->head.magic); __put_user(sizeof(struct target_fpsimd_context), &fpsimd->head.size); __put_user(vfp_get_fpsr(env), &fpsimd->fpsr); __put_user(vfp_get_fpcr(env), &fpsimd->fpcr); for (i =3D 0; i < 32; i++) { uint64_t *q =3D aa64_vfp_qreg(env, i); #ifdef TARGET_WORDS_BIGENDIAN __put_user(q[0], &fpsimd->vregs[i * 2 + 1]); __put_user(q[1], &fpsimd->vregs[i * 2]); #else __put_user(q[0], &fpsimd->vregs[i * 2]); __put_user(q[1], &fpsimd->vregs[i * 2 + 1]); #endif } } Where our layout for the quads is always: Qn =3D regs[n].d[1]:regs[n].d[0] -- Alex Benn=C3=A9e