From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98413 invoked by alias); 6 Aug 2018 18:29:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 98403 invoked by uid 89); 6 Aug 2018 18:29:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=Supply, extract, 2886, Hx-languages-length:3097 X-HELO: sesbmg22.ericsson.net Received: from sesbmg22.ericsson.net (HELO sesbmg22.ericsson.net) (193.180.251.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Aug 2018 18:29:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533580160; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6VdNgobgxkVkAsZJlpHe6qxLG40pRFbAoUqdhu3OIKw=; b=HXE82Adh3EruuwKUZMxjVSovX5ydBJ/aC7vu3rHa10atyTM34pbpBuhCr3hinv1F +D2faI41v7JTsmq06tt6IUspVJ1vqhOnd4uLkUWhy6GNWuBIut67NhvolpfZckow 9+yt7US+5oo7k58L4kIeRGI5siJ9NJDfKX2z5TslYi4=; Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 70.72.21978.083986B5; Mon, 6 Aug 2018 20:29:20 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 6 Aug 2018 20:29:20 +0200 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 6 Aug 2018 20:29:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VcQYLrUbZXoArcACWHsyMHx6XaFTwOwH5naABkPpTwg=; b=YLdiHFA0RZSSJ9oBpqDLMTmo1UWtIlhQnCmHP/3UtcJMZRbiSdeDUk4ATq23feDV5Q6LOW2J2Px2zoDmCmU6x0DEWRmtOW0+WsSMk5uKsuVSi15B02DnL8AOPMpN8pU5b/u8S4G9Z84Oki0LVx6eBOF5/8/FobJncE+hkqQN1n0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [142.133.48.222] (192.75.88.130) by BN7PR15MB2386.namprd15.prod.outlook.com (2603:10b6:406:8c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Mon, 6 Aug 2018 18:29:16 +0000 Subject: Re: [PATCH v2 3/3] Parse SVE registers in aarch64 core file reading/writing To: Alan Hayward , CC: References: <20180730092528.98739-1-alan.hayward@arm.com> <20180730092528.98739-4-alan.hayward@arm.com> From: Simon Marchi Message-ID: Date: Mon, 06 Aug 2018 18:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180730092528.98739-4-alan.hayward@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-Path: simon.marchi@ericsson.com Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00101.txt.bz2 On 2018-07-30 05:25 AM, Alan Hayward wrote: > sve_regmap cannot be global static as the size is dependant on the current > vector length. > > 2018-07-30 Alan Hayward > > * aarch64-linux-tdep.c (aarch64_linux_supply_sve_regset): New function. > (aarch64_linux_collect_sve_regset): Likewise. > (aarch64_linux_iterate_over_regset_sections): Check for SVE. > * regcache.h (regcache_map_entry_size): New function. > --- > gdb/aarch64-linux-tdep.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++- > gdb/regcache.h | 8 ++++ > 2 files changed, 118 insertions(+), 2 deletions(-) > > diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c > index f9a95950da..bd61a2d722 100644 > --- a/gdb/aarch64-linux-tdep.c > +++ b/gdb/aarch64-linux-tdep.c > @@ -288,6 +288,85 @@ aarch64_linux_core_read_vq (struct gdbarch *gdbarch, bfd *abfd) > return vq; > } > > +/* Supply register REGNUM from BUF to REGCACHE, using the register map > + in REGSET. If REGNUM is -1, do this for all registers in REGSET. > + If BUF is NULL, set the registers to "unavailable" status. */ > + > +static void > +aarch64_linux_supply_sve_regset (const struct regset *regset, > + struct regcache *regcache, > + int regnum, const void *buf, size_t size) > +{ > + struct gdbarch *gdbarch = regcache->arch (); > + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > + > + if (buf == nullptr) > + return regcache->supply_regset (regset, regnum, nullptr, size); > + gdb_assert (size > SVE_HEADER_SIZE); > + > + /* BUF contains an SVE header followed by a register dump of either the > + passed in SVE regset or a NEON fpregset. */ > + > + /* Extract required fields from the header. */ > + uint64_t vg = sve_vg_from_vl (SVE_HEADER_READ (buf, 2, byte_order)); > + uint16_t flags = SVE_HEADER_READ (buf, 4, byte_order); > + > + if (regnum == -1 || regnum == AARCH64_SVE_VG_REGNUM) > + regcache->raw_supply (AARCH64_SVE_VG_REGNUM, &vg); I think this raw_supply is wrong. The vg local variable is in host byte order, but the data in the buffer passed to raw_supply should be in target. So you may need to do a store_unsigned_integer in a buffer and supply that. If this is a pattern that happens often enough, maybe it would be worth having a raw_supply that does this conversion from integer to register buffer, a bit like "regcache::raw_write (int regnum, T val)" does. > + > + if (flags & 1) > + { > + /* Register dump is a SVE structure. */ > + regcache->supply_regset (regset, regnum, > + (gdb_byte *) buf + SVE_HEADER_SIZE, > + size - SVE_HEADER_SIZE); > + } > + else > + { > + /* Register dump is a fpsimd structure. First clear the SVE > + registers. */ > + for (int i = 0; i < AARCH64_SVE_Z_REGS_NUM; i++) > + regcache->raw_supply_zeroed (AARCH64_SVE_Z0_REGNUM + i); > + for (int i = 0; i < AARCH64_SVE_P_REGS_NUM; i++) > + regcache->raw_supply_zeroed (AARCH64_SVE_P0_REGNUM + i); > + regcache->raw_supply_zeroed (AARCH64_SVE_FFR_REGNUM); Just wondering, should they be made unavailable instead of cleared? Simon