From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9753 invoked by alias); 7 Jun 2019 09:39:06 -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 9745 invoked by uid 89); 7 Jun 2019 09:39:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1169 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Jun 2019 09:39:05 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E4EFB360; Fri, 7 Jun 2019 02:39:03 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C50F93F96A; Fri, 7 Jun 2019 02:39:02 -0700 (PDT) Date: Fri, 07 Jun 2019 09:39:00 -0000 From: Will Deacon To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, gdb@sourceware.org, Alex =?iso-8859-1?Q?Benn=E9e?= , Julien Grall , Catalin Marinas , Peter Maydell , Zhang Lei Subject: Re: [PATCH 0/2] arm64/sve: Fix mutating register endianness on big-endian Message-ID: <20190607093858.GA21378@fuggles.cambridge.arm.com> References: <1559839495-22315-1-git-send-email-Dave.Martin@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1559839495-22315-1-git-send-email-Dave.Martin@arm.com> User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () X-SW-Source: 2019-06/txt/msg00008.txt.bz2 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