Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

randen_hwaes compilation error on aarch64 #662

Closed
iceboy233 opened this issue Apr 11, 2020 · 8 comments
Closed

randen_hwaes compilation error on aarch64 #662

iceboy233 opened this issue Apr 11, 2020 · 8 comments
Assignees

Comments

@iceboy233
Copy link

The error message is:

In file included from external/com_google_absl/absl/random/internal/randen_hwaes.cc:225:0:
external/org_linaro_components_toolchain_gcc_aarch64/lib/gcc/aarch64-linux-gnu/7.4.1/include/arm_neon.h: In function 'Vector128 {anonymous}::AesRound(const Vector128&, const Vector128&)':
external/org_linaro_components_toolchain_gcc_aarch64/lib/gcc/aarch64-linux-gnu/7.4.1/include/arm_neon.h:12440:1: error: inlining failed in call to always_inline 'uint8x16_t vaesmcq_u8(uint8x16_t)': target specific option mismatch
 vaesmcq_u8 (uint8x16_t data)
 ^~~~~~~~~~
external/com_google_absl/absl/random/internal/randen_hwaes.cc:251:20: note: called from here
   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;
          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from external/com_google_absl/absl/random/internal/randen_hwaes.cc:225:0:
external/org_linaro_components_toolchain_gcc_aarch64/lib/gcc/aarch64-linux-gnu/7.4.1/include/arm_neon.h:12426:1: error: inlining failed in call to always_inline 'uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)': target specific option mismatch
 vaeseq_u8 (uint8x16_t data, uint8x16_t key)
 ^~~~~~~~~
external/com_google_absl/absl/random/internal/randen_hwaes.cc:251:20: note: called from here
   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;

Looks like when crypto is not supported, the compiler cannot generate some instructions. Adding -march=armv8-a+crypto resolves the problem but forces hardware crypto.

@iceboy233
Copy link
Author

iceboy233 commented Apr 11, 2020

I also have one idea here - randen currently uses software AES when hardware AES is not supported, according to my benchmark, this is 10x slower on x64. What about using chacha (or speck if block cipher is desired) as the polyfill when hardware AES is not supported?

@derekmauro
Copy link
Member

It looks like the problem here is that https://github.com/abseil/abseil-cpp/blob/master/absl/copts/configure_copts.bzl has the symbol ABSL_RANDOM_HWAES_ARM64_FLAGS but never uses it. Our internal version of this file does use it, but it gets stripped out before it reaches GitHub, for reasons that are complicated. It should be fixable.

I think using ChaCha when hardware acceleration isn't available is a reasonable idea, but we likely won't be able to work on it for a while. I should also point out that absl::BitGen explicitly says that should not be considered a secure generator, in case you thought it is. If you need speed on ARM, consider using absl::InsecureBitGen, which is currently based on pcg and shouldn't rely on hardware acceleration to get good speed.

@RBEGamer
Copy link

/home/marcel/Desktop/atc_buildroot/src/src_buildroot/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/include/arm_neon.h: In function ‘Vector128 {anonymous}::AesRound(const Vector128&, const Vector128&)’: /home/marcel/Desktop/atc_buildroot/src/src_buildroot/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/include/arm_neon.h:16925:1: error: inlining failed in call to always_inline ‘uint8x16_t vaesmcq_u8(uint8x16_t)’: target specific option mismatch 16925 | vaesmcq_u8 (uint8x16_t __data) | ^~~~~~~~~~ internal/randen_hwaes.cc:251:20: note: called from here 251 | return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key; | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from internal/randen_hwaes.cc:225: /home/marcel/Desktop/atc_buildroot/src/src_buildroot/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/include/arm_neon.h:16911:1: error: inlining failed in call to always_inline ‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’: target specific option mismatch 16911 | vaeseq_u8 (uint8x16_t __data, uint8x16_t __key) | ^~~~~~~~~ internal/randen_hwaes.cc:251:20: note: called from here 251 | return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key; | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ make[4]: *** [absl/random/CMakeFiles/random_internal_randen_hwaes_impl.dir/build.make:82: absl/random/CMakeFiles/random_internal_randen_hwaes_impl.dir/internal/randen_hwaes.cc.o] Error 1
Have the same problems, building with buildroot for ARM / RPI3b

@shivaji17
Copy link

Is there any work around for this?

copybara-service bot pushed a commit to google/xls that referenced this issue Feb 17, 2021
Towards #286
Workaround for abseil/abseil-cpp#662

PiperOrigin-RevId: 357990845
@patrickdepinguin
Copy link

I see the same issue building for 32-bit ARM on an AArch64 platform (also using Buildroot).

Note that Buildroot does not use the Bazel backend, but cmake. In the cmake files I do see that the ABSL_RANDOM_HWAES_ARM64_FLAGS / ABSL_RANDOM_HWAES_ARM32_FLAGS are respected. Yet the problem remains.

The full command-line with output is:

'.../buildroot/output/host/opt/ext-toolchain/bin/arm-cortex_a53-linux-gnueabi-g++' \
'--sysroot' '.../buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot' \
'-mabi=aapcs-linux' \
'-mfpu=neon-fp-armv8' \
'-marm' \
'-mfloat-abi=hard' \
'--sysroot=.../buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot' \
'-Drandom_internal_randen_hwaes_impl_EXPORTS' \
'-I.../buildroot/output/build/libabseil-cpp-20200923.3' \
'-D_LARGEFILE_SOURCE' \
'-D_LARGEFILE64_SOURCE' \
'-D_FILE_OFFSET_BITS=64' \
'-Os' \
'-g2' \
'-DNDEBUG' \
'-DNDEBUG' \
'-fPIC' \
'-Wall' \
'-Wextra' \
'-Wcast-qual' \
'-Wconversion-null' \
'-Wmissing-declarations' \
'-Woverlength-strings' \
'-Wpointer-arith' \
'-Wundef' \
'-Wunused-local-typedefs' \
'-Wunused-result' \
'-Wvarargs' \
'-Wvla' \
'-Wwrite-strings' \
'-Wno-missing-field-initializers' \
'-Wno-sign-compare' \
'-DNOMINMAX' \
'-mfpu=neon' \
'-std=gnu++11' \
'-o' 'CMakeFiles/random_internal_randen_hwaes_impl.dir/internal/randen_hwaes.cc.o' \
'-c' '.../buildroot/output/build/libabseil-cpp-20200923.3/absl/random/internal/randen_hwaes.cc'

In file included from .../buildroot/output/build/libabseil-cpp-20200923.3/absl/random/internal/randen_hwaes.cc:229:0:
.../buildroot/output/host/opt/ext-toolchain/arm/lib/gcc/arm-cortex_a53-linux-gnueabi/7.4.0/include/arm_neon.h: In function 'Vector128 {anonymous}::AesRound(const Vector128&, const Vector128&)':
.../buildroot/output/host/opt/ext-toolchain/arm/lib/gcc/arm-cortex_a53-linux-gnueabi/7.4.0/include/arm_neon.h:16925:1: error: inlining failed in call to always_inline 'uint8x16_t vaesmcq_u8(uint8x16_t)': target specific option mismatch
 vaesmcq_u8 (uint8x16_t __data)
 ^~~~~~~~~~
.../buildroot/output/build/libabseil-cpp-20200923.3/absl/random/internal/randen_hwaes.cc:255:20: note: called from here
   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;
          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from .../buildroot/output/build/libabseil-cpp-20200923.3/absl/random/internal/randen_hwaes.cc:229:0:
.../buildroot/output/host/opt/ext-toolchain/arm/lib/gcc/arm-cortex_a53-linux-gnueabi/7.4.0/include/arm_neon.h:16911:1: error: inlining failed in call to always_inline 'uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)': target specific option mismatch
 vaeseq_u8 (uint8x16_t __data, uint8x16_t __key)
 ^~~~~~~~~
.../buildroot/output/build/libabseil-cpp-20200923.3/absl/random/internal/randen_hwaes.cc:255:20: note: called from here
   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;
          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The first -mfpu=neon-fp-armv8 is added by Buildroot, and -mfpu=neon is the flag added by libabseil-cpp. I tried removing either one and both, but this made no difference.

But when I change the parameter to -mfpu=crypto-neon-fp-armv8, then the error disappears.

@asoffer
Copy link
Contributor

asoffer commented Jun 30, 2021

We're still looking in to this, though haven't prioritized it. PRs certainly welcome, as this is not a place we have significant expertise, though we are investigating solutions.

@markub3327
Copy link
Contributor

markub3327 commented Jul 1, 2021

With CMake compilation is working well:

./example/hello_world.cc

#include <iostream>
#include <string>
#include <vector>

#include "absl/strings/str_join.h"
#include "absl/random/random.h"

int main() {
  std::vector<std::string> v = {"foo", "bar", "baz"};
  std::string s = absl::StrJoin(v, "-");

  absl::BitGen bitgen;

  std::cout << "Joined string: " << s << "\n";
  std::cout << "Number: " << absl::Uniform(bitgen, 0, 1.0) << "\n"; 

  return 0;
}
ubuntu@NVIDIA-01:~/Projects/TestProject/build$ cmake ..
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ubuntu/Projects/TestProject/build

ubuntu@NVIDIA-01:~/Projects/TestProject/build$ cmake --build . --target hello_world
[  3%] Built target absl_log_severity
[  6%] Built target absl_raw_logging_internal
[  9%] Built target absl_bad_optional_access
[ 12%] Built target absl_spinlock_wait
[ 21%] Built target absl_base
[ 27%] Built target absl_throw_delegate
[ 30%] Built target absl_int128
[ 33%] Built target absl_random_internal_platform
[ 36%] Built target absl_random_internal_randen_hwaes_impl
[ 39%] Built target absl_random_internal_randen_hwaes
[ 45%] Built target absl_random_internal_randen_slow
[ 48%] Built target absl_random_internal_randen
[ 51%] Built target absl_random_seed_gen_exception
[ 57%] Built target absl_strings_internal
[ 81%] Built target absl_strings
[ 84%] Built target absl_random_distributions
[ 87%] Built target absl_random_internal_seed_material
[ 90%] Built target absl_random_internal_pool_urbg
[ 93%] Built target absl_random_seed_sequences
[100%] Built target hello_world

./CMakeLists.txt

cmake_minimum_required(VERSION 3.5)

project(my_project)

# Abseil requires C++11
set(CMAKE_CXX_STANDARD 11)

# Process Abseil's CMake build system
add_subdirectory(abseil-cpp)

add_executable(hello_world hello_world.cc)

# Declare dependency on the absl::strings library
target_link_libraries(hello_world absl::strings)
target_link_libraries(hello_world absl::random_random)

I have the issue only with Bazel:

./example/BUILD

cc_binary(
  name = "hello_world",
  deps = ["@com_google_absl//absl/strings", "@com_google_absl//absl/random"],
  srcs = ["hello_world.cc"],
)

./WORKSPACE

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
  name = "com_google_absl",
  urls = ["https://github.com/abseil/abseil-cpp/archive/98eb410c93ad059f9bba1bf43f5bb916fc92a5ea.zip"],
  strip_prefix = "abseil-cpp-98eb410c93ad059f9bba1bf43f5bb916fc92a5ea",
)

ERROR

ubuntu@NVIDIA-01:~/Projects/my_workspace$ bazel build //example:hello_world
DEBUG: Rule 'com_google_absl' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "aabf6c57e3834f8dc3873a927f37eaf69975d4b28117fc7427dfb1c661542a87"
DEBUG: Repository com_google_absl instantiated at:
  /home/ubuntu/Projects/my_workspace/WORKSPACE:3:13: in <toplevel>
Repository rule http_archive defined at:
  /home/ubuntu/.cache/bazel/_bazel_ubuntu/b8008d82eb65899d4e39675de40d6cec/external/bazel_tools/tools/build_defs/repo/http.bzl:336:31: in <toplevel>
INFO: Analyzed target //example:hello_world (7 packages loaded, 98 targets configured).
INFO: Found 1 target...
ERROR: /home/ubuntu/.cache/bazel/_bazel_ubuntu/b8008d82eb65899d4e39675de40d6cec/external/com_google_absl/absl/random/internal/BUILD.bazel:331:11: C++ compilation of rule '@com_google_absl//absl/random/internal:randen_hwaes_impl' failed (Exit 1): gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 31 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 31 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
In file included from external/com_google_absl/absl/random/internal/randen_hwaes.cc:225:0:
/usr/lib/gcc/aarch64-linux-gnu/7/include/arm_neon.h: In function 'Vector128 {anonymous}::AesRound(const Vector128&, const Vector128&)':
/usr/lib/gcc/aarch64-linux-gnu/7/include/arm_neon.h:12440:1: error: inlining failed in call to always_inline 'uint8x16_t vaesmcq_u8(uint8x16_t)': target specific option mismatch
 vaesmcq_u8 (uint8x16_t data)
 ^~~~~~~~~~
external/com_google_absl/absl/random/internal/randen_hwaes.cc:251:20: note: called from here
   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;
          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from external/com_google_absl/absl/random/internal/randen_hwaes.cc:225:0:
/usr/lib/gcc/aarch64-linux-gnu/7/include/arm_neon.h:12426:1: error: inlining failed in call to always_inline 'uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)': target specific option mismatch
 vaeseq_u8 (uint8x16_t data, uint8x16_t key)
 ^~~~~~~~~
external/com_google_absl/absl/random/internal/randen_hwaes.cc:251:20: note: called from here
   return vaesmcq_u8(vaeseq_u8(state, uint8x16_t{})) ^ round_key;
          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-pass-failed'
Target //example:hello_world failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 8.358s, Critical Path: 2.18s
INFO: 14 processes: 3 internal, 11 linux-sandbox.
FAILED: Build did NOT complete successfully

How can I redefine BUILD or WORKSPACE to make building successful?
What is the difference between Bazel and CMake in this case?

Thanks.

@derekmauro
Copy link
Member

This should be fixed by 2e94e5b.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants
@derekmauro @asoffer @iceboy233 @patrickdepinguin @RBEGamer @shivaji17 @markub3327 and others