Asan output not symbolized

[Jeffrey Walton]

Hi Everyone,

I have a test script from help that repeatedly builds and runs a
library under different configurations. The script includes multiple
Asan tests.

The Asan tests are producing some findings under ARM32 as shown below.
Other platforms do not include Asan findings. In addition, Valgrind
does nt produce any findings.

The test program is always built with at least -g2, and sometimes
built with -g3. However, I am not seeing the symbolication. According
to the GCC folks, asan_symbolize is not required for GCC because it
uses libbacktrace. Also see
http://bugzilla.redhat.com/show_bug.cgi?id=1250844.

Why am I lacking symbolization, and how do I achieve it?

**

AddressSanitizer: stack-buffer-overflow on address 0xbec57b18 at pc
0x38c651 bp 0xbec579e0 sp 0xbec579e4

AddressSanitizer: stack-buffer-overflow on address 0xbedbae9c at pc
0x6553f bp 0xbedbae68 sp 0xbedbae6c

AddressSanitizer: stack-buffer-overflow on address 0xbea67b18 at pc
0x38cbc5 bp 0xbea679e0 sp 0xbea679e4

AddressSanitizer: stack-buffer-overflow on address 0xbef0fe9c at pc
0x66117 bp 0xbef0fe68 sp 0xbef0fe6c

**

$ uname -a
Linux cubietruck 3.4.39 #35 SMP PREEMPT Tue Sep 15 17:17:33 CST 2015
armv7l armv7l armv7l GNU/Linux

$ g++ --version
g++ (Ubuntu/Linaro 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

vreinterpretq_*_p128 for converting from polynomials?

[Jeffrey Walton]

Hi Everyone,

I'm having trouble finding vreinterpretq_u64_p128 (and friends) to
help convert a polynomial. I can't find it in arm_neon.h or
arm_acle.h:

$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
$ grep p64 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
$ grep p64 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
vmull_p64 (poly64_t a, poly64_t b)
vmull_high_p64 (poly64x2_t a, poly64x2_t b)
$

An RPI-3 with ARMv8/Aarch32 and GCC 4.9.2 has it in arm_neon.h:

$ cat /usr/lib/gcc/arm-linux-gnueabihf/4.9.2/include/arm_neon.h | grep
-A 4 vreinterpretq_u64_p128
vreinterpretq_u64_p128 (poly128_t __a)
{
  return (uint64x2_t)__builtin_neon_vreinterpretv2diti
((__builtin_neon_ti) __a);
}

Is there another file that should be included for it? Or is there
something else I should be doing when I want to convert from a
polynomial to a type like uint64x2_t?

Thanks in advance.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

[Jeffrey Walton]

Hi Everyone,

I'm looking at the features of a BeagleBone Black. Its /proc/cpuinfo is below.

I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags
neon and vfpv3 flags means I want something more than -mfpu=neon-fp16,
but I'm not sure what that is.

My question is, what GCC ARM option is used when we encounter the
neon, vfpv3 and vfpd32 flags?

Thanks in advance.

**

$ cat /proc/cpuinfo
processor: 0
model name: ARMv7 Processor rev 2 (v7l)
BogoMIPS: 996.14
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer: 0x41
CPU architecture: 7
CPU variant: 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: Generic AM33XX (Flattened Device Tree)
Revision: 
Serial: 
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

[Jeffrey Walton]

On Thu, Jul 21, 2016 at 11:30 PM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Thu, Jul 21, 2016 at 6:33 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags
>> neon and vfpv3 flags means I want something more than -mfpu=neon-fp16,
>> but I'm not sure what that is.
>
> neon implies vfvp3 and 32 D-registers and asimd/neon support, so that
> part is correct.  it isn't obvious to me if you have the
> half-precision float support.  The "half" printed by the kernel means
> that half-word loads are supported, which is only false for some
> obsolete parts I think.  The kernel doesn't appear to be checking to
> see if the hardware has half-precision float support or not, so you
> can't determine that from /proc/cpuinfo.

Thanks Jim.

Is there an arm-msr-tools or similar that has setuid so we can access the MSRs?

My thinking is, I can tell people to install arm-msr-tools so we can
query for the features directly. I want to avoid telling people to run
a test script as root.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

[Jeffrey Walton]

On Thu, Jul 21, 2016 at 11:30 PM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Thu, Jul 21, 2016 at 6:33 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags
>> neon and vfpv3 flags means I want something more than -mfpu=neon-fp16,
>> but I'm not sure what that is.
>
> neon implies vfvp3 and 32 D-registers and asimd/neon support, so that
> part is correct.  it isn't obvious to me if you have the
> half-precision float support.  The "half" printed by the kernel means
> that half-word loads are supported, which is only false for some
> obsolete parts I think.  The kernel doesn't appear to be checking to
> see if the hardware has half-precision float support or not, so you
> can't determine that from /proc/cpuinfo.

OK, so looking at
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html,
it appears the "minimum" of the -mfpu option is VFPv3-D16. Since I
have 32 D-regs, I can use the one VFPv3-D32, which should equate to
-mfpu=neon-vfp3 (which does not seem to exist).

I can't use -mfpu=neon-vfpv4 because vfpv4 is not signaled, and it
could be missing the half word and fma extensions implied with vfpv4.

So I guess the question is, what do I use for -mfpu=neon-vfp3 (or
-mfpu=neon-vfp3-d32)? Is -mfpu=neon enough?

Thanks again for the help with this.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

[Jeffrey Walton]

On Fri, Jul 22, 2016 at 12:19 AM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Thu, Jul 21, 2016 at 9:13 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> So I guess the question is, what do I use for -mfpu=neon-vfp3 (or
>> -mfpu=neon-vfp3-d32)? Is -mfpu=neon enough?
>
> The -mfpu=neon option is enough.  neon implies vfpv3 and 32 D registers.

Perfect, thanks.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Compile error when building an Aarch32 program on Aarch64?

[Jeffrey Walton]

Hi Everyone,

I have a HiKey running Linaro. I'm trying to build out a test case
which tests Aarch32 on Aarch64.

When I attempt to build an Aarch32 binary I experience the compile
error below. The GCC folks helped me with the Aarch32 CFLAGS, so I
believe they are correct.

$ gcc -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard test.cc -o test.exe
gcc: error: unrecognized command line option ‘-mfpu=crypto-neon-fp-armv8’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’

Trying an -m32:

$ gcc -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -m32 test.cc -o test.exe
gcc: error: unrecognized command line option ‘-mfpu=crypto-neon-fp-armv8’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’
gcc: error: unrecognized command line option ‘-m32’

And without the -mtune:

$ gcc -march=armv8-a+crc -mfpu=crypto-neon-fp-armv8
-mfloat-abi=hard test.cc -o test.exe
gcc: error: unrecognized command line option ‘-mfpu=crypto-neon-fp-armv8’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’

I'm obviously suffering a disconnect. I may have more problems after
the build when attempting to run the program, but I'll cross that
bridge when I encounter it.

How does one build an Aarch32 program on Aarch64?

Thanks in advance.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: vreinterpretq_*_p128 for converting from polynomials?

[Jeffrey Walton]

On Thu, Jul 28, 2016 at 12:28 PM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Thu, Jul 28, 2016 at 8:36 AM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> I'm having trouble finding vreinterpretq_u64_p128 (and friends) to
>> help convert a polynomial. I can't find it in arm_neon.h or
>> arm_acle.h:
>
>> An RPI-3 with ARMv8/Aarch32 and GCC 4.9.2 has it in arm_neon.h:
>
> Yes, these *p128* intrinsics are missing from the aarch64 port.  I'd
> suggest filing a bug report.

Thanks Jim.

Please forgive my ignorance. Who gets the report? Linaro, Debian or GCC?

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: vreinterpretq_*_p128 for converting from polynomials?

[Jeffrey Walton]

On Sat, Jul 30, 2016 at 12:07 AM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Fri, Jul 29, 2016 at 7:55 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>>> Yes, these *p128* intrinsics are missing from the aarch64 port.  I'd
>>> suggest filing a bug report.
>>
>> Please forgive my ignorance. Who gets the report? Linaro, Debian or GCC?
>
> The FSF GCC bugzilla.
> https://gcc.gnu.org/bugzilla/

Perfect, thanks, done. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=72758 .

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

-mfpu=neon-fp-armv8 and unrecognized command line option

[Jeffrey Walton]

Hi Everyone,

I'm having trouble with ARMv8/Aarch64. One is an early Mustang server
board (without CRC or Crypto), and the other is a LeMaker HiKey (with
CRC and Crypto). Both run Linaro:

apm-mustang: $ cat /proc/cpuinfo
Features: fp asimd evtstrm

And:

hikey: $ cat /proc/cpuinfo
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32

According to the GCC folks, we can get better code generation with
-mfpu=neon-fp-armv8
(http://gcc.gnu.org/ml/gcc-help/2016-05/msg00058.html and
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html). However, it
results in:

$ g++ -DDEBUG -g3 -O0 -mfpu=neon-fp-armv8 -fPIC -pipe -c cryptlib.cpp
g++: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’
GNUmakefile:753: recipe for target 'cryptlib.o' failed

It looks like -mfpu=neon-fp-armv8 is a GCC 4.9 feature
(http://gcc.gnu.org/gcc-4.9/changes.html), and Linaro supplies GCC
4.9.2:

$ g++ --version
g++ (Debian/Linaro 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

I'm wonder why the option is not being consumed by GCC. Are there any
ideas what I should be doing differently?

Thanks in advance.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: -mfpu=neon-fp-armv8 and unrecognized command line option

[Jeffrey Walton]

On Wed, Jul 20, 2016 at 5:33 PM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Wed, Jul 20, 2016 at 2:14 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> I'm having trouble with ARMv8/Aarch64. One is an early Mustang server
>
> ARMv8 implies 32-bit code (aarch32).  Aaarch64 implies 64-bit code.
> These are two different compilers, with two different sets of command
> line options.

Thanks Jim. According to ARM, ARMv8 is 64-bit
(http://www.arm.com/products/processors/armv8-architecture.php). Maybe
I'm parsing the page incorrectly?

(Note that I'm aware of Aarch32 execution environments on Aarch64. I'm
not trying for that test case at the moment).

>> $ g++ -DDEBUG -g3 -O0 -mfpu=neon-fp-armv8 -fPIC -pipe -c cryptlib.cpp
>> g++: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’
>> GNUmakefile:753: recipe for target 'cryptlib.o' failed
>
> -mfpu=neon-fp-armv8 is an arm (32-bit) compiler option.  The aarch64
> (64-bit) compiler will not accept it.
>
> Because FP and Neon support is optional in the 32-bit arm
> architecture, there are compiler options to enable fp and/or neon
> support.  Usually FP support is enabled by default for a linux distro,
> but the neon support usually is not, and you can enable neon by using
> this -mcpu=neon-fp-armv8 option if running 32-bit code on an ARMv8
> architecture part.

OK, thanks. So is neon-fp-armv8 an Aarch32 execution environment option?

> Meanwhile, the aarch64 spec requires FP and ASIMD instruction support
> in the linux ABI, so there are no options to enable them, they are on
> by default.

Yeah, I was clear on asimd being ARM-64's equivalent to NEON and it
was enabled by default.

> If you really want to disable them, you can do so by
> using a -march= option, e.g. -march=aarch64+fp+simd enables them, and
> -march=aarch64+nofp+nosimd disables them.  However, if you disable fp
> support,

Oh, NO. We want to test under them. Sorry about the confusion.

> you will break the ABI, and your code may not compile or run,
> so don't do that unless perhaps you have an embedded target, and have
> your own OS build and your own ABI. or no code that uses FP  You can
> also enable/.disable crc (crypto) support this way, but a better way
> is to use a -mcpu= option, and let gcc figure out if the target has
> crc instructions.
>
> See the aarch64 compiler docs here
> https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options

So it looks like the course of action is to simply remove it from
http://github.com/weidai11/cryptopp/blob/master/cryptest.sh#L874 . (It
was added recently because of the ML recommendation).

These ARM options are awful. I spent the better part of a day trying
to untangle the option combinations to ensure we are getting good test
coverage in a test script. I'd give my left arm device for a compiler
that provides -march=native or -mfpu=native and gets it right.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Asan output not symbolized

[Jeffrey Walton]

>> Mystery solved... GCC 4.8 does not provide a symbolizer.
>>
>> From a new comment on the GCC bug report
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1250844#c6):
>
> Even with symbolizer you may face some issue with ASAN on ARM.
> Check this llvm bug report [1].
>
> [1] https://llvm.org/bugs/show_bug.cgi?id=22741

Thanks, that makes sense. I could not understand why code that had
been stable for nearly 20 years was producing a finding under GCC 4.8
Asan.

The next mystery is why its producing a finding at all.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Asan output not symbolized

[Jeffrey Walton]

On Sun, Jun 26, 2016 at 10:33 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
> Hi Everyone,
>
> I have a test script from help that repeatedly builds and runs a
> library under different configurations. The script includes multiple
> Asan tests.
>
> The Asan tests are producing some findings under ARM32 as shown below.
> Other platforms do not include Asan findings. In addition, Valgrind
> does nt produce any findings.
>
> The test program is always built with at least -g2, and sometimes
> built with -g3. However, I am not seeing the symbolication. According
> to the GCC folks, asan_symbolize is not required for GCC because it
> uses libbacktrace. Also see
> http://bugzilla.redhat.com/show_bug.cgi?id=1250844.
>
> Why am I lacking symbolization, and how do I achieve it?

Mystery solved... GCC 4.8 does not provide a symbolizer.

From a new comment on the GCC bug report
(https://bugzilla.redhat.com/show_bug.cgi?id=1250844#c6):

>> I don't know what is different about things on my CubieTruck5 (Linaro, GCC
>> 4.8.2), but I had to use asan_symbolize provided by Clang/Asan to get
>> symbols for a GCC/Asan finding.
>
> Everything is different in this regard between 4.8.x and 4.9.x.  Only the 
> latter
> has libbacktrace symbolization built in, the former doesn't have any
> symbolization.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Asan output not symbolized

[Jeffrey Walton]

>> The test program is always built with at least -g2, and sometimes
>> built with -g3. However, I am not seeing the symbolication. According
>> to the GCC folks, asan_symbolize is not required for GCC because it
>> uses libbacktrace. Also see
>> http://bugzilla.redhat.com/show_bug.cgi?id=1250844.
>>
>> Why am I lacking symbolization, and how do I achieve it?
>
> Are these full backtraces you got from ASan? If so, do you use stripped
> libraries on your system (on Ubuntu, I guess, you do). Could this issue
> (https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00132.html) be related to to
> your problem?
>

Not stripped; they are [supposed to be] fully symbolized. Here's the
CXXFLAGS used. Link occurs using $CXX with CXXFLAGS.

$ cat asan-output.txt
$ export CXXFLAGS="-DDEBUG -g3 -O0 -std=c++03 -mfpu=neon -fPIC
-fsanitize=address -fno-omit-frame-pointer -D_GLIBCXX_DEBUG"
...

We use one directory for *.h and *.cpp files. In addition, *.o files
go in the same directory. We do it to avoid problems with debuggers
finding symbols (it minimizes user questions).

Here's the full output, if interested: http://pastebin.com/Zn4ADDQ6.
It looks like there's some unbounded recursion going on, too.

Let me look into the bug, thanks.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Does Linaro's GCC 4.9 include Crypto extensions and intrinsics?

[Jeffrey Walton]

Please forgive my ignorance. I'm working on a Pine64 dev-board Pine64
supplies Linaro's GCC 4.9.2 toolchain.

I am catching a compile error, and I am trying to determine why.

Does Linaro's GCC 4.9 provide AES and SHA intrinsics?

**

$ uname -a
Linux pine64 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16
10:53:13 CEST 2016 aarch64 GNU/Linux

$ gcc --version
gcc (Debian/Linaro 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

**

$ CFLAGS="-DMBEDTLS_HAVE_ARMV8A_CE=1" make DEBUG=1 V=1
  CCaes_armv8a_ce.c
aes_armv8a_ce.c: In function 'mbedtls_armv8a_ce_aes_crypt_ecb':
aes_armv8a_ce.c:65:4: warning: implicit declaration of function
'vaeseq_u8' [-Wimplicit-function-declaration]
state_vec = vaeseq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c:65:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaeseq_u8( state_vec, roundkey_vec );
  ^
aes_armv8a_ce.c:67:4: warning: implicit declaration of function
'vaesmcq_u8' [-Wimplicit-function-declaration]
state_vec = vaesmcq_u8( state_vec );
^
aes_armv8a_ce.c:67:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaesmcq_u8( state_vec );
  ^
aes_armv8a_ce.c:74:13: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
   state_vec = vaeseq_u8( state_vec, roundkey_vec );
 ^
aes_armv8a_ce.c:84:4: warning: implicit declaration of function
'vaesdq_u8' [-Wimplicit-function-declaration]
state_vec = vaesdq_u8( state_vec, roundkey_vec );
^
aes_armv8a_ce.c:84:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaesdq_u8( state_vec, roundkey_vec );
  ^
aes_armv8a_ce.c:86:4: warning: implicit declaration of function
'vaesimcq_u8' [-Wimplicit-function-declaration]
state_vec = vaesimcq_u8( state_vec );
^
aes_armv8a_ce.c:86:14: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
state_vec = vaesimcq_u8( state_vec );
  ^
aes_armv8a_ce.c:93:13: error: incompatible types when assigning to
type 'uint8x16_t' from type 'int'
   state_vec = vaesdq_u8( state_vec, roundkey_vec );
 ^
aes_armv8a_ce.c: In function 'mbedtls_armv8a_ce_gcm_mult':
aes_armv8a_ce.c:138:2: warning: implicit declaration of function
'vmull_high_p64' [-Wimplicit-function-declaration]
  r1 = (uint8x16_t)vmull_high_p64( (poly64x2_t)a_p, (poly64x2_t)b_p );
  ^
aes_armv8a_ce.c:138:2: error: can't convert between vector values of
different size
aes_armv8a_ce.c:141:2: error: can't convert between vector values of
different size
  t0 = (uint8x16_t)vmull_high_p64( (poly64x2_t)a_p, (poly64x2_t)t0 );
  ^
aes_armv8a_ce.c:150:2: error: can't convert between vector values of
different size
  t0 = (uint8x16_t)vmull_high_p64( (poly64x2_t)r1, (poly64x2_t)p );
  ^
Makefile:170: recipe for target 'aes_armv8a_ce.o' failed
make[1]: *** [aes_armv8a_ce.o] Error 1
Makefile:17: recipe for target 'lib' failed
make: *** [lib] Error 2

**

  CCsha1_armv8a_ce.c
sha1_armv8a_ce.c: In function 'mbedtls_armv8a_ce_sha1_process':
sha1_armv8a_ce.c:99:2: warning: implicit declaration of function
'vsha1h_u32' [-Wimplicit-function-declaration]
  e1 = vsha1h_u32( a );
  ^
sha1_armv8a_ce.c:100:2: warning: implicit declaration of function
'vsha1cq_u32' [-Wimplicit-function-declaration]
  abcd = vsha1cq_u32( abcd, e, wk0 ); /* 0 */
  ^
sha1_armv8a_ce.c:100:7: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
  abcd = vsha1cq_u32( abcd, e, wk0 ); /* 0 */
   ^
sha1_armv8a_ce.c:102:2: warning: implicit declaration of function
'vsha1su0q_u32' [-Wimplicit-function-declaration]
  w0 = vsha1su0q_u32( w0, w1, w2 );
  ^
sha1_armv8a_ce.c:102:5: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
  w0 = vsha1su0q_u32( w0, w1, w2 );
 ^
sha1_armv8a_ce.c:106:7: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
  abcd = vsha1cq_u32( abcd, e1, wk1 ); /* 1 */
   ^
sha1_armv8a_ce.c:108:2: warning: implicit declaration of function
'vsha1su1q_u32' [-Wimplicit-function-declaration]
  w0 = vsha1su1q_u32( w0, w3 );
  ^
sha1_armv8a_ce.c:108:5: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
  w0 = vsha1su1q_u32( w0, w3 );
 ^
sha1_armv8a_ce.c:109:5: error: incompatible types when assigning to
type 'uint32x4_t' from type 'int'
  w1 = vsha1su0q_u32( w1, w2, w3 );
 ^
...

**

$ grep -IR vaeseq_u8 /usr/include
/usr/include/clang/3.5.0/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
/usr/include/clang/3.5.0/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
/usr/include/clang/3.5/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
/usr/include/clang/3.5/include/arm_neon.h:__ai uint8x16_t
vaeseq_u8(uint8x16_t __p0, 

Re: Does Linaro's GCC 4.9 include Crypto extensions and intrinsics?

[Jeffrey Walton]

Thanks guys, that was it.

I did not realize the build system was omitting the flags.

On Fri, Jan 13, 2017 at 2:23 AM, Pinski, Andrew
<andrew.pin...@cavium.com> wrote:
> Can you try -march=armv8+crypto ?
>
> -Original Message-
> From: linaro-toolchain [mailto:linaro-toolchain-boun...@lists.linaro.org] On 
> Behalf Of Jeffrey Walton
> Sent: Thursday, January 12, 2017 10:56 PM
> To: Linaro Toolchain Mailman List <linaro-toolchain@lists.linaro.org>
> Subject: Does Linaro's GCC 4.9 include Crypto extensions and intrinsics?
>
> Please forgive my ignorance. I'm working on a Pine64 dev-board Pine64 
> supplies Linaro's GCC 4.9.2 toolchain.
>
> I am catching a compile error, and I am trying to determine why.
>
> Does Linaro's GCC 4.9 provide AES and SHA intrinsics?
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Error: unknown pseudo-op: `.arch_extension'

[Jeffrey Walton]

> I don't see any easy solution for you at the moment, you need a
> binutils/gcc upgrade, or you need to put crc code in separate files.
> Or you could force all files to be compiled with -mcpu=generic, and
> then you can use .cpu to add/remove crc support as necessary.

Thanks Jim. This came from Jiong Wang on the Binutils mailing list
(https://sourceware.org/ml/binutils/2017-04/msg00171.html):

__inline unsigned int GCC_INLINE_ATTRIB
CRC32B(unsigned int crc, unsigned char v)
{
unsigned int r;
asm ("\t.set raw_x0, 0\n"
 "\t.set raw_x1, 1\n"
 "\t.set raw_x2, 2\n"
 "\t.set raw_x3, 3\n"
 "\t.set raw_x4, 4\n"
 "\t.set raw_x5, 5\n"
 "\t.set raw_x6, 6\n"
 "\t.set raw_x7, 7\n"
 "\t#crc32w %w2, %w1, %w0\n"
 "\t.inst\t0x1ac04800 | (raw_%2) | (raw_%1 << 5) | (raw_%0 << 16)\n"
 : "=r"(r) : "r"(crc), "r"((unsigned int)v)
);
return r;
}

Thanks for the help (and thanks to the Binutil folks). I would not
have gotten this far on my own.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Error: unknown pseudo-op: `.arch_extension'

[Jeffrey Walton]

On Wed, Apr 19, 2017 at 9:57 PM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Wed, Apr 19, 2017 at 12:38 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> According to [1], I can use ".arch_extension" to enable it. According
>> to [2], ".arch_extension" is available in GCC 4.6 and GAS 2.21. My
>> version of Linaro provides GCC 4.9.2 and GAS 2.25.90. I can also
>> duplicate the issue on GCC113 (compiel farm), which provides GCC 4.8
>> and GAS 2.24.
>
> ARM is a little ambiguous.  It turns out that arch_extension was added
> to the arm (32-bit) port in 2010, but wasn't added to the aarch64
> (64-bit) port until 2014.
> So you need binutils-2.26 in order to use arch_extension pseudo-op
> with the aarch64 toolchain.
>
> Meanwhile, you might try looking at the arm_neon.h header file for
> your gcc version.  Though it apperas in gcc-4.9.2 there is only a
> predefined macro __ARM_FEATURE_CRYPTO that you can use, and nothing
> for CRC.  GCC 5.x adds a __ARM_FEATURE_CRC32 predefined macro that you
> could use.
>
> With gcc 6, the arm_neon.h file uses
> #pragma GCC push_options
> #pragma GCC target ("+nothing+crypto")
> ...
> #pragma GCC pop_options
> to enable crypto support.  You can do something similar with crc, you
> probably want to use "+onthing+crc" if you only want crc support
> enalbed, or "+simd+crc" if you want both simd and crc support enabled
> for instance.
>
> The GCC aarch64 port does not use the arch64_extension support in binutils.
>
> I think the linux kernel just puts functions that need crc support in
> different files, so that those files can be compiled with crc support
> enabled via -mcpu=generic+crc.

Ah, thanks Jim. That would have taken me a long time to discover.

I've had some success with something similar to the kernel method. The
program below works with GCC 4.8, 4.9 and later.

The thing I am not sure about is saving and restoring the cpu. The AS
manual states "Specifying .cpu clears any previously selected
architecture extensions". But arch_extensions does not seem to work,
so I guess its a moot point. Also, the manual only discusses '.set' in
the context of MIPS. The program below does not produce a warning or
error. I am not sure if its doing what's expected.

I'm trying to avoid adding an additional source file for each source
file that uses NEON, CRC or CRYPTO. We are a C++ project, and it means
moving functions out of headers and into source files. Additionally,
we have 175 source files (plus headers), and the strategy could double
the counts.

Our choices are kind of crummy at this point...

Jeff

$ cat test.cxx
#include 
#include 

#define GCC_INLINE_ATTRIB __attribute__((__gnu_inline__,
__always_inline__, __artificial__))

#if defined(__GNUC__) && !defined(__ARM_FEATURE_CRC32)
__inline unsigned int GCC_INLINE_ATTRIB
CRC32B(unsigned int crc, unsigned char v)
{
unsigned int r;
asm (".set push, .cpu  \n"
 ".cpu generic+crc  \n"
 "crc32w %w2, %w1, %w0 \n"
 ".set pop, .cpu   \n"
 : "=r"(r) : "r"(crc), "r"((unsigned int)v));
return r;
}
#else
   // just use the intrinsic
# define CRC32B(a,b) __crc32b(a,b)
#endif

int main(int argc, char* argv[])
{
return CRC32B(argc, argc);
}
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Q: reasons for lack of support for C++ in OP-TEE?

[Jeffrey Walton]

On Sat, Aug 12, 2017 at 1:27 AM, Michael Zimmermann
 wrote:
> That also depends on what you want to use C++ for.
> If you just want to use the convenient syntax and language features
> then you don't need to link against any additional library.
> In that case you'd disable exceptions and rtti and implement
> new/delete using malloc/free.

Instead of pounding a round peg into a square hole with C++, maybe the
path to pursue is GCC support for try/finally in C. You get most of
the semantics you are looking for, and someone as experienced as you
will know exactly what to do with the feature.

Lack of try/finally support means library often do awful things.
Asterisk was full of issues, like resource leaks, that try/finally
would have fixed. Eventually Asterisk moved to nested/inner functions
and trampolines. They silently lost NX stacks, which was a cure as bad
as the disease. It just moved problems around rather than fixing them.

Microsoft compilers support try/finally in C. I recall a GCC bug
report years ago asking for it, but it was declined.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Problems with Aarch64 vmull_p64 and vmull_high_p64

[Jeffrey Walton]

On Sun, Jul 30, 2017 at 7:30 PM, Jim Wilson <jim.wil...@linaro.org> wrote:
> On Sun, Jul 30, 2017 at 1:32 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> hikey$ g++ -march=armv8-a test.cxx -c
>> test.cxx: In function ‘poly128_t VMULL_P64(poly64_t, poly64_t)’:
>> test.cxx:10:1: error: unrecognizable insn:
>
> pmull is part of the crypto extension, which is not enabled by
> default.  You need to use -march=armv8-a+crypto.  Or else specify a

Thanks Jim.

The odd thing is, ARM's ACLE [1], Section 6.5.4 (p.24),  states Crypto
applies to
AES{E, D} and SHA1{C, P, M}. It does not mention PMULL. Later it goes
on to state PMULL gear is available on Aarch32 and Aarch64.

Jeff

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Problems with Aarch64 vmull_p64 and vmull_high_p64

[Jeffrey Walton]

Hi Everyone,

I'm working on a early LeMaker HiKey with GCC 4.9.2. I believe
everything is fully patched.

I'm using the builtin's because the intrinsics are missing. I lifted
it from https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01976.html.

Any ideas on this issue?

hikey$ g++ -march=armv8-a test.cxx -c
test.cxx: In function ‘poly128_t VMULL_P64(poly64_t, poly64_t)’:
test.cxx:10:1: error: unrecognizable insn:
 }
 ^
(insn 9 8 12 2 (set (reg:TI 73 [ D.17869 ])
(unspec:TI [
(reg:DI 75)
(reg:DI 76)
] UNSPEC_PMULL)) test.cxx:9 -1
 (nil))
test.cxx:10:1: internal compiler error: in extract_insn, at recog.c:2202
Please submit a full bug report,

Thanks in advance.

Jeff

**

hikey:cryptopp-fork$ cat test.cxx
#include 
#include 

#define GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 +
__GNUC_PATCHLEVEL__)

#if (GCC_VERSION >= 40800) && (GCC_VERSION < 5)
inline poly128_t VMULL_P64(poly64_t a, poly64_t b)
{
return __builtin_aarch64_crypto_pmulldi_ppp (a, b);
}

inline poly128_t VMULL_HIGH_P64(poly64x2_t a, poly64x2_t b)
{
return __builtin_aarch64_crypto_pmullv2di_ppp (a, b);
}
#else
# define VMULL_P64(a, b) vmull_p64(a, b)
# define VMULL_HIGH_P64(a, b) vmull_high_p64(a, b)
#endif

int main(int argc, char* argv[])
{
const poly64_t   a1={0x9090909090909090}, b1={0xb0b0b0b0b0b0b0b0};
const poly8x16_t
a2={0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0,0xa0},

b2={0xc0,0xc0,0xc0,0xc0,0xc0,0xc0,0xc0,0xc0,0xe0,0xe0,0xe0,0xe0,0xe0,0xe0,0xe0,0xe0};

const poly128_t r1 = VMULL_P64(a1, b1);
const poly128_t r2 = VMULL_HIGH_P64((poly64x2_t)(a2), (poly64x2_t)(b2));

return 0;
}

**

$ cat /proc/cpuinfo
Processor   : AArch64 Processor rev 3 (aarch64)
processor   : 0
processor   : 1
processor   : 2
processor   : 3
processor   : 4
processor   : 5
processor   : 6
processor   : 7
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: AArch64
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 3

Hardware: HiKey Development Board

**

$ gcc --version
gcc (Debian/Linaro 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 8.9 (jessie)
Release:8.9
Codename:   jessie
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: ARM GCC 8.x Performance Dropping Compared to Linaro GCC 7.x

[Jeffrey Walton]

On Fri, Aug 23, 2019 at 2:15 AM Maxim Kuvyrkov
 wrote:
>
> ...
> The other 1/3 will require much more work -- neon intrinsics needs to be 
> converted from inline asms to GCC builtins, so that we can attach scheduler 
> descriptions to them.

Please do.

I know of at least two libraries that heavily rely on ARMv8 intrinsics
in some areas. Performance is better than C/C++, but it is kind of
flat overall. Stack Overflow also has several questions about poor
intrinsics performance on ARM.

Jeff
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain