From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97137 invoked by alias); 6 Aug 2018 18:28: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 97014 invoked by uid 89); 6 Aug 2018 18:28:25 -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 autolearn=ham version=3.3.2 spammy=fan X-HELO: sesbmg23.ericsson.net Received: from sesbmg23.ericsson.net (HELO sesbmg23.ericsson.net) (193.180.251.37) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Aug 2018 18:28:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533580101; 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=kSURrCcS71iNZgeU1TXzyqJ4mjM9YuZF6jF//gpYxTI=; b=ZcX9JJepYnHs7oPWGNvr7W4jGMXBbNWbiUXbEEHL3RqErcvQH4TDTaQ5u0QV5g03 11kmA4HKowaLXu6GOoLuMgRahRU1LJOskHq7coc3nrSDcbDuRve1O5dNM9iNuiPG gV1RfBpvtvaXrT2oRWeMmUDLD90FrzuIakgV0YgLFCY=; Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.DD.27833.543986B5; Mon, 6 Aug 2018 20:28:21 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMB502.ericsson.se (153.88.183.163) 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:28:19 +0200 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) 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:28:19 +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=qcDph6yMrKp9UmAk5OPT2m64Ft8aaeyN6skmdr6vb+o=; b=Jo74GFLgCBEbbwLQ0VYjSux4XAMJB3OF94AmRaDe/bImDzgL6jm24Jedm4cyON+6LSkEFbemqqN70kW+4oX9EBTkImKMUGoaQpgJCC9NEsLnhX7K18JBwWz2oFRDVaP3iOI7ZEKhLFA2L5CdMZ+dQO7VdgUdwfZ8ZPvBaM1N9u4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [142.133.48.222] (192.75.88.130) by BN7PR15MB2388.namprd15.prod.outlook.com (2603:10b6:406:8c::26) 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:28:16 +0000 Subject: Re: [PATCH v2 2/3] Detect SVE when reading aarch64 core files To: Alan Hayward , CC: References: <20180730092528.98739-1-alan.hayward@arm.com> <20180730092528.98739-3-alan.hayward@arm.com> From: Simon Marchi Message-ID: <0734eec8-9e70-d364-259a-719e2d210df0@ericsson.com> Date: Mon, 06 Aug 2018 18:28: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-3-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/msg00100.txt.bz2 On 2018-07-30 05:25 AM, Alan Hayward wrote: > Add a function which reads the vector length from the SVE section within an > aarch64 core file. > > The SVE section in a core file contains a header followed by the registers. > All macros to parse access this structure. > > 2018-07-30 Alan Hayward > > * aarch64-linux-tdep.c (struct struct_contents): Add struct. > (SVE_HEADER_SIZE): Add Macro. > (SVE_HEADER_WRITE): Likewise. > (SVE_HEADER_READ): Likewise. > (aarch64_linux_core_read_vq): Add function. > (aarch64_linux_core_read_description): Check for SVE section. > --- > gdb/aarch64-linux-tdep.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 71 insertions(+), 3 deletions(-) > > diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c > index 7b63cddbe6..f9a95950da 100644 > --- a/gdb/aarch64-linux-tdep.c > +++ b/gdb/aarch64-linux-tdep.c > @@ -219,6 +219,75 @@ const struct regset aarch64_linux_fpregset = > regcache_supply_regset, regcache_collect_regset > }; > > +/* Description of the fields in an SVE header at the start of a SVE regset. */ > + > +struct struct_contents { > + int len; > + int offset; > +} sve_header[] = > + { > + { 4, 0 }, /* __u32 size. */ > + { 4, 4 }, /* __u32 max_size. */ > + { 2, 8 }, /* __u16 vl. */ > + { 2, 10 }, /* __u16 max_vl. */ > + { 2, 12 }, /* __u16 flags. */ > + { 2, 14 }, /* __u16 reserved. */ > + { -1, 16 } > + }; I don't think the resulting code is very readable, for example this bit from the next patch: SVE_HEADER_WRITE (buf, 0, byte_order, size); SVE_HEADER_WRITE (buf, 1, byte_order, size); SVE_HEADER_WRITE (buf, 2, byte_order, sve_vl_from_vq (vq)); SVE_HEADER_WRITE (buf, 3, byte_order, sve_vl_from_vq (vq)); SVE_HEADER_WRITE (buf, 4, byte_order, 1); SVE_HEADER_WRITE (buf, 5, byte_order, 0); Maybe have some macros to access the index of the fields in the structure, like this? #define SVE_HEADER_SIZE_FIELD 0 #define SVE_HEADER_MAX_SIZE_FIELD 1 #define SVE_HEADER_VL_FIELD 2 ... > + > +#define SVE_HEADER_SIZE (sve_header[6].offset) Perhaps use ARRAY_SIZE (sve_header) - 1 instead of 6? > + > +#define SVE_HEADER_WRITE(header, entry, byte_order, value) \ > + store_unsigned_integer ((gdb_byte *) header + sve_header[entry].offset, \ > + sve_header[entry].len, byte_order, value) > + > +#define SVE_HEADER_READ(header, entry, byte_order) \ > + extract_unsigned_integer ((gdb_byte *) header + sve_header[entry].offset, \ > + sve_header[entry].len, byte_order) I'm not a big fan of macros when the same work can be done with a function, which seems to be the case here. > + > +/* Get VQ value from SVE section in the core dump. */ > + > +static uint64_t > +aarch64_linux_core_read_vq (struct gdbarch *gdbarch, bfd *abfd) > +{ > + gdb_byte header[SVE_HEADER_SIZE]; > + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > + asection *sve_section = bfd_get_section_by_name (abfd, ".reg-aarch-sve"); > + > + if (!sve_section) == nullptr > + { > + /* No SVE state. */ > + return 0; > + } > + > + size_t size = bfd_section_size (abfd, sve_section); > + > + /* Check extended state size. */ > + if (size < SVE_HEADER_SIZE) > + { > + warning (_("'.reg-aarch-sve' section in core file too small.")); > + return 0; > + } > + > + if (!bfd_get_section_contents (abfd, sve_section, header, 0, SVE_HEADER_SIZE)) > + { > + warning (_("Couldn't read sve header from " > + "'.reg-aarch-sve' section in core file.")); > + return 0; > + } > + > + uint64_t vq = sve_vq_from_vl (SVE_HEADER_READ (header, 2, byte_order)); > + > + if (vq > AARCH64_MAX_SVE_VQ) > + { > + warning (_("sve header invalid in " > + "'.reg-aarch-sve' section in core file.")); > + return 0; > + } Is 0 a valid value for vq (in other words, should it show a warning)? Simon