From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128457 invoked by alias); 14 Dec 2016 09:28:35 -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 128440 invoked by uid 89); 14 Dec 2016 09:28:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=doctype, !doctype, uint32, contributed X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Dec 2016 09:28:24 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D91ADAD7; Wed, 14 Dec 2016 01:28:22 -0800 (PST) Received: from [10.37.9.6] (unknown [10.37.9.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id E9B1F3F3D6; Wed, 14 Dec 2016 01:28:17 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.0.161029 Date: Wed, 14 Dec 2016 09:28:00 -0000 Subject: Re: [PATCH 5/8] AARCH64 SVE: Add SVE feature From: Alan Hayward To: Yao Qi CC: "gdb-patches@sourceware.org" Message-ID: References: <20161213175130.GG25542@E107787-LIN> In-Reply-To: <20161213175130.GG25542@E107787-LIN> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-SW-Source: 2016-12/txt/msg00294.txt.bz2 On 13/12/2016 17:51, "Yao Qi" wrote: >On 16-12-05 12:28:45, Alan Hayward wrote: >> This is part of a series adding AARCH64 SVE support to gdb and >>gdbserver. >>=20 >> This patch adds the SVE feature. >>=20 >> This code sets size of the variable registers to 64bits for the Z >>registers >> and 8bits for the P registers. It will be the job of the aarch64 target >> code > >What is the reason to set Z registers 64-bit and P registers 8-bit? >According to reference in the cover letter, Z register is 128 bit in >minimum and P register is 16-bit in minimum. The DWARF spec requires that we have a DWARF VG register (defined as the number of 64bit chunks in a Z register). Therefore we end up with a VG register in gdb, which the user can see also see. However all the linux #defines (as copied from ptrace.h in patch 6) use VL (the number of 128bit chunks in a Z register). I thought it was more consistent to use VG throughout GDB as VG is the value the gdb user can see in the register bank. If I switched to using VL then this would have minor code benefit (reduce the size of one array of pointers and remove a few asserts checks), but nothing else. I=E2=80=99m happy to make the switch to VL if people think that is better. > >> (in a later patch in the series) to scale the Z and P registers to the >> correct size using the integer scalar VG. > >> diff --git a/gdb/features/aarch64-sve-core.xml >> b/gdb/features/aarch64-sve-core.xml >> new file mode 100644 >> index=20 >>=20 >>0000000000000000000000000000000000000000..d990aebfa1d8d17cc53a70a6c751753 >>3f >> 8e369b9 >> --- /dev/null >> +++ b/gdb/features/aarch64-sve-core.xml >> @@ -0,0 +1,105 @@ >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + > >It should describe the right size of register"z0". According to the >reference, the minimum is 128-bits and max is 2048-bits. There are >16 possibilities. We can either generate all of them (16) ahead of >time or we can create a template, like this, > > > ... > > >and reply the right one back to GDB with the UNIT replaced by a >proper value. > >We still have feature "org.gnu.gdb.aarch64.sve", but the size of >Z and P registers may be different. > >I still need some time to think about the best way to get >target description dynamically. My original plan was to write something similar to your bitsize=3D"128 * UNIT" suggestion. However, all attempts ended up with adding lots code to the common xml parsing just to support SVE. It gets even more difficult with the creation of the aarch64-sve.dat file (would we want multiple of these? That would get messy if max vector length grew in future SVE revisions.) I felt the neatest and simplest way was to leave the xml simple and add a few lines to fix up the target description in the aarch64 code. If we use VL instead of VG then the above code will have 128bits for the Z registers, which will be correct for the smallest possible SVE implementation. Would that be ok? > >> diff --git a/gdb/gdbserver/Makefile.in b/gdb/gdbserver/Makefile.in >> index=20 >>=20 >>5316c95b67f04591c448a8a14b4ed3cac0092666..3b175caeb0807fd315baa35dbb8e340 >>65 >> 32a335e 100644 >> --- a/gdb/gdbserver/Makefile.in >> +++ b/gdb/gdbserver/Makefile.in >> @@ -418,7 +418,7 @@ clean: >> rm -f version.c >> rm -f gdbserver$(EXEEXT) gdbreplay$(EXEEXT) core make.log >> rm -f $(IPA_LIB) >> - rm -f aarch64.c >> + rm -f aarch64.c aarch64-sve.c >> rm -f reg-arm.c reg-bfin.c i386.c reg-ia64.c reg-m32r.c reg-m68k.c >> rm -f reg-sh.c reg-sparc.c reg-spu.c amd64.c i386-linux.c >> rm -f reg-cris.c reg-crisv32.c amd64-linux.c reg-xtensa.c >> @@ -607,6 +607,9 @@ linux-aarch64-ipa.o: linux-aarch64-ipa.c >> aarch64-ipa.o: aarch64.c >> $(IPAGENT_COMPILE) $< >> $(POSTCOMPILE) >> +aarch64-sve-ipa.o: aarch64-sve.c >> + $(IPAGENT_COMPILE) $< >> + $(POSTCOMPILE) > >We don't support tracepoint for SVE, so no need to build >aarch64-sve-ipa.o. Ok. > >--=20 >Yao (=E9=BD=90=E5=B0=A7)