[PATCH 5/8] AARCH64 SVE: Add SVE feature

Alan Hayward alan.hayward@arm.com
Wed Dec 14 09:28:00 GMT 2016



On 13/12/2016 17:51, "Yao Qi" <qiyaoltc@gmail.com> 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.
>> 
>> This patch adds the SVE feature.
>> 
>> 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’m 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 
>> 
>>0000000000000000000000000000000000000000..d990aebfa1d8d17cc53a70a6c751753
>>3f
>> 8e369b9
>> --- /dev/null
>> +++ b/gdb/features/aarch64-sve-core.xml
>> @@ -0,0 +1,105 @@
>> +<?xml version="1.0"?>
>> +<!-- Copyright (C) 2009-2015 Free Software Foundation count="Inc.
>> +     Contributed by ARM Ltd.
>> +
>> +     Copying and distribution of this file count="with or without
>> modification,
>> +     are permitted in any medium without royalty provided the copyright
>> +     notice and this notice are preserved.  -->
>> +
>> +<!DOCTYPE feature SYSTEM "gdb-target.dtd">
>> +<feature name="org.gnu.gdb.aarch64.sve">
>> +
>> +  <vector id="svevdf" type="ieee_double" count="1"/>
>> +  <vector id="svevdu" type="uint64" count="1"/>
>> +  <vector id="svevds" type="int64" count="1"/>
>> +  <vector id="svevsf" type="ieee_single" count="2"/>
>> +  <vector id="svevsu" type="uint32" count="2"/>
>> +  <vector id="svevss" type="int32" count="2"/>
>> +  <vector id="svevhu" type="uint16" count="4"/>
>> +  <vector id="svevhs" type="int16" count="4"/>
>> +  <vector id="svevbu" type="uint8" count="8"/>
>> +  <vector id="svevbs" type="int8" count="8"/>
>> +  <union id="svevnd">
>> +    <field name="f" type="svevdf"/>
>> +    <field name="u" type="svevdu"/>
>> +    <field name="s" type="svevds"/>
>> +  </union>
>> +  <union id="svevns">
>> +    <field name="f" type="svevsf"/>
>> +    <field name="u" type="svevsu"/>
>> +    <field name="s" type="svevss"/>
>> +  </union>
>> +  <union id="svevnh">
>> +    <field name="u" type="svevhu"/>
>> +    <field name="s" type="svevhs"/>
>> +  </union>
>> +  <union id="svevnb">
>> +    <field name="u" type="svevbu"/>
>> +    <field name="s" type="svevbs"/>
>> +  </union>
>> +  <union id="svev">
>> +    <field name="d" type="svevnd"/>
>> +    <field name="s" type="svevns"/>
>> +    <field name="h" type="svevnh"/>
>> +    <field name="b" type="svevnb"/>
>> +  </union>
>> +
>> +  <vector id="svep" type="uint8" count="1"/>
>> +
>> +  <reg name="z0" bitsize="64" type="svev" regnum="34"/>
>
>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,
>
>  <vector id="svevdf" type="ieee_double" count="2 * UNIT"/>
>  ...
>  <reg name="z0" bitsize="128 * UNIT" type="svev" regnum="34"/>
>
>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="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 
>> 
>>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.

>
>-- 
>Yao (齐尧)




More information about the Gdb-patches mailing list