From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14532 invoked by alias); 12 Jun 2019 10:40:19 -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 14514 invoked by uid 89); 12 Jun 2019 10:40:18 -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=views X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Jun 2019 10:40:16 +0000 Received: by mail-wr1-f68.google.com with SMTP id x4so13684033wrt.6 for ; Wed, 12 Jun 2019 03:40:15 -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=XmccsWJR/T+DLcAFqKC/hfzAgkjoCq+zFw+LQmVavW0=; b=tB/ymDm6xCjEd6EdcVSeBIyWpqLZvr5OMN5CBA5vDv8F4EB6jWepFYmon9O0q4lFBp i4wH5KhJn8Aij4Zsv5Z947Kj6MGHj9MN5Ke6pbMocbvue61tt8xuoR8h663WD4FU/6y3 NmPC+rpQG1bl4EKNoMG+6M2mOevf7dAQ0Vg9zX71oH+DU02H5zLykFC8o9tl2rZtdauN +f3gwXRuo9fsMRPW3mqEwli3uZ4dxUQZfLuNAXTzp87eXvFB/PWWM9WkHZC5v28/ITC4 EhwezEmufesOiSJ2tTlQxpSH/NKAN8yPIt4GWbS+FbSc1pHAl8sek16tLL+kU4Emposl 2Zmg== Return-Path: Received: from zen.linaroharston ([81.128.185.34]) by smtp.gmail.com with ESMTPSA id g5sm20846550wrp.29.2019.06.12.03.40.12 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 12 Jun 2019 03:40:12 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 040201FF87; Wed, 12 Jun 2019 11:40:12 +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> User-agent: mu4e 1.3.2; emacs 26.1 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Alan Hayward Cc: Dave P Martin , Will Deacon , Peter Maydell , Catalin Marinas , "Zhang Lei" , Julien Grall , "gdb\@sourceware.org" , "linux-arm-kernel\@lists.infradead.org" , nd Subject: Re: [PATCH 0/2] arm64/sve: Fix mutating register endianness on big-endian In-reply-to: <207E140D-AC57-4B0D-B838-94B92BE2B0A0@arm.com> Date: Wed, 12 Jun 2019 10:40:00 -0000 Message-ID: <87v9xbdr3o.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/msg00018.txt.bz2 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 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? >> >> 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. -- Alex Benn=C3=A9e