This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/2] arm64/sve: Fix mutating register endianness on big-endian
- From: Will Deacon <will dot deacon at arm dot com>
- To: Dave Martin <Dave dot Martin at arm dot com>
- Cc: linux-arm-kernel at lists dot infradead dot org, gdb at sourceware dot org, Alex Bennée <alex dot bennee at linaro dot org>, Julien Grall <julien dot grall at arm dot com>, Catalin Marinas <catalin dot marinas at arm dot com>, Peter Maydell <peter dot maydell at linaro dot org>, Zhang Lei <zhang dot lei at jp dot fujitsu dot com>
- Date: Fri, 7 Jun 2019 10:38:58 +0100
- Subject: Re: [PATCH 0/2] arm64/sve: Fix mutating register endianness on big-endian
- References: <1559839495-22315-1-git-send-email-Dave.Martin@arm.com>
On Thu, Jun 06, 2019 at 05:44:53PM +0100, Dave Martin wrote:
> By inspection while debugging something else, I noticed that the byte
> 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 FPSIMD
> 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 are
> also affected. The KVM ABI forbids mixing the two views and so should
> not be affected.
>
> See patch 2 for details.
>
> Patch 1 does some trivial preparatory refactoring.
Sorry to be a pain, but would you be able to flip this series round so that
the fix doesn't depend on the refactoring, please? That way we can put it
into stable without the dependency.
> gdb may or may not be affected by this, depending on how it uses the
> NT_PRFPREG and NT_ARM_SVE regsets. I'll leave it to the developers to
> assess that.
Wouldn't this be easy enough to test?
Will