kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
1d1345377a
boringssl/CMakeLists.txt

603 lines
24 KiB
CMake
Raw Normal View History

Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
cmake_minimum_required(VERSION 2.8.11)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
Disable Clang -Wtautological-constant-compare. This is a recent Clang warning, but it's far too aggressive. The earlier unsigned long silliness was worth fixing, but it otherwise complains on 32-bit platforms with: if (some_size_t > 0xffffffff) { ... } which is unreasonable as, on 64-bit platforms, this check is meaningful and requiring the programmer add ifdefs is error-prone. This matches Chromium in https://crbug.com/767059. Bug: chromium:767059 Change-Id: I0bb0f3a4b60f222e9d1b3c569471fbcf5518caed Reviewed-on: https://boringssl-review.googlesource.com/23845 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2017-12-04 22:19:49 +00:00
# Report AppleClang separately from Clang. Their version numbers are different.
# https://cmake.org/cmake/help/v3.0/policy/CMP0025.html
if(POLICY CMP0025)
cmake_policy(SET CMP0025 NEW)
endif()
Prefer MSVC over GCC if both are in %PATH%. Notably, putting Strawberry Perl in %PATH% will usually end up putting a copy of gcc in %PATH%, which trips up people trying to build on Windows. This is arguably misusing the variable (normally set by the generator), but it should work. Change-Id: I13a011eb33688ae928a56cce266edd2759a3cb32 Reviewed-on: https://boringssl-review.googlesource.com/7070 Reviewed-by: Adam Langley <agl@google.com>
2016-02-06 02:58:39 +00:00
# Defer enabling C and CXX languages.
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
project(BoringSSL NONE)
Prefer MSVC over GCC if both are in %PATH%. Notably, putting Strawberry Perl in %PATH% will usually end up putting a copy of gcc in %PATH%, which trips up people trying to build on Windows. This is arguably misusing the variable (normally set by the generator), but it should work. Change-Id: I13a011eb33688ae928a56cce266edd2759a3cb32 Reviewed-on: https://boringssl-review.googlesource.com/7070 Reviewed-by: Adam Langley <agl@google.com>
2016-02-06 02:58:39 +00:00
if(WIN32)
# On Windows, prefer cl over gcc if both are available. By default most of
# the CMake generators prefer gcc, even on Windows.
set(CMAKE_GENERATOR_CC cl)
endif()
Convert aes_test to GTest. This introduces machinery to start embedding the test data files into the crypto_test binary. Figuring out every CI's test data story is more trouble than is worth it. The GTest FileTest runner is considerably different from the old one: - It returns void and expects failures to use the GTest EXPECT_* and ASSERT_* macros, rather than ExpectBytesEqual. This is more monkey work to convert, but ultimately less work to add new tests. I think it's also valuable for our FileTest and normal test patterns to align as much as possible. The line number is emitted via SCOPED_TRACE. - I've intentionally omitted the Error attribute handling, since that doesn't work very well with the new callback. This means evp_test.cc will take a little more work to convert, but this is again to keep our two test patterns aligned. - The callback takes a std::function rather than a C-style void pointer. This means we can go nuts with lambdas. It also places the path first so clang-format doesn't go nuts. BUG=129 Change-Id: I0d1920a342b00e64043e3ea05f5f5af57bfe77b3 Reviewed-on: https://boringssl-review.googlesource.com/16507 Reviewed-by: Adam Langley <agl@google.com>
2017-05-19 20:26:18 +01:00
include(sources.cmake)
Prefer MSVC over GCC if both are in %PATH%. Notably, putting Strawberry Perl in %PATH% will usually end up putting a copy of gcc in %PATH%, which trips up people trying to build on Windows. This is arguably misusing the variable (normally set by the generator), but it should work. Change-Id: I13a011eb33688ae928a56cce266edd2759a3cb32 Reviewed-on: https://boringssl-review.googlesource.com/7070 Reviewed-by: Adam Langley <agl@google.com>
2016-02-06 02:58:39 +00:00
enable_language(C)
enable_language(CXX)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
Support symbol prefixes - In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
# This is a dummy target which all other targets depend on (manually - see other
# CMakeLists.txt files). This gives us a hook to add any targets which need to
# run before all other targets.
add_custom_target(global_target)
Add support for building with the Android NDK. Previously I've been using the Linaro toolchains and just building static binaries. However, the Linaro toolchains have a broken pthread_rwlock_wrlock—it does nothing and then unlocking corrupts the lock. Building with the Android NDK avoids this. These build instructions depend on https://github.com/taka-no-me/android-cmake which people will need to clone into util/ if they want to use the Android NDK. Change-Id: Ic64919f9399af2a57e8df4fb4b3400865ddb2427 Reviewed-on: https://boringssl-review.googlesource.com/4600 Reviewed-by: Adam Langley <agl@google.com>
2015-04-29 01:46:58 +01:00
if(ANDROID)
# Android-NDK CMake files reconfigure the path and so Go and Perl won't be
# found. However, ninja will still find them in $PATH if we just name them.
Fix discovery rule for perl and go for Android We don't use find_package/find_program on android to find go/perl because the android toolchain reconfigure the $PATH. The pervious way of solving this was to let ninja look for go/perl on the $PATH but this approach prevented us from specifying explicit go/perl executables what is needed for hermetic build using prebuilts. This CL changes the Android specific discovery rule to only set GO_EXECUTABLE and PERL_EXECUTABLE if they are not specified on the command line or inside the toolchain file. Change-Id: Ib6ef69707749073f2b79244ebb301502b2a5a34a Reviewed-on: https://boringssl-review.googlesource.com/8000 Reviewed-by: David Benjamin <davidben@google.com>
2016-05-19 14:28:14 +01:00
if(NOT PERL_EXECUTABLE)
set(PERL_EXECUTABLE "perl")
endif()
if(NOT GO_EXECUTABLE)
set(GO_EXECUTABLE "go")
endif()
Add support for building with the Android NDK. Previously I've been using the Linaro toolchains and just building static binaries. However, the Linaro toolchains have a broken pthread_rwlock_wrlock—it does nothing and then unlocking corrupts the lock. Building with the Android NDK avoids this. These build instructions depend on https://github.com/taka-no-me/android-cmake which people will need to clone into util/ if they want to use the Android NDK. Change-Id: Ic64919f9399af2a57e8df4fb4b3400865ddb2427 Reviewed-on: https://boringssl-review.googlesource.com/4600 Reviewed-by: Adam Langley <agl@google.com>
2015-04-29 01:46:58 +01:00
else()
find_package(Perl REQUIRED)
find_program(GO_EXECUTABLE go)
endif()
Find perl using the CMake's standard FindPerl module. This gives a standard PERL_EXECUTABLE configuration knob which is useful for specifying a perl to use without having it in PATH. Change-Id: I4b196b77e0b4666081a3f291fee3654c47925844 Reviewed-on: https://boringssl-review.googlesource.com/3570 Reviewed-by: Adam Langley <agl@google.com>
2015-02-23 18:06:19 +00:00
Don't look for libunwind if cross-compiling. pkg-config gets confused and doesn't know to look in, say, /usr/lib/i386-linux-gnu when building for 32-bit. Fortunately, CMake sets a CMAKE_CROSSCOMPILING variable whenever CMAKE_SYSTEM_NAME is set manually (as done in util/32-bit-toolchain.cmake). Change-Id: I638b4d54ea92ade4b2b5baa40a3c5e8c17914d46 Reviewed-on: https://boringssl-review.googlesource.com/c/34305 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2019-01-15 18:45:57 +00:00
if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND NOT CMAKE_CROSSCOMPILING)
Make pkg-config optional. Since libunwind, and therefore the CFI tests, are already optional, might as well make pkg-config optional too. (I'm not sure whether we actually want to support people using our development build, but gRPC appear to be trying to do so: https://github.com/grpc/grpc/issues/17638) Change-Id: I16b4c53bd8a66933bc19fba29aed0d79ce2670c2 Reviewed-on: https://boringssl-review.googlesource.com/c/34124 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2019-01-04 15:53:25 +00:00
find_package(PkgConfig QUIET)
if (PkgConfig_FOUND)
pkg_check_modules(LIBUNWIND libunwind-generic)
if(LIBUNWIND_FOUND)
add_definitions(-DBORINGSSL_HAVE_LIBUNWIND)
else()
message("libunwind not found. Disabling unwind tests.")
endif()
Add a CFI tester to CHECK_ABI. This uses the x86 trap flag and libunwind to test CFI works at each instruction. For now, it just uses the system one out of pkg-config and disables unwind tests if unavailable. We'll probably want to stick a copy into //third_party and perhaps try the LLVM one later. This tester caught two bugs in P-256 CFI annotations already: I47b5f9798b3bcee1748e537b21c173d312a14b42 and I9f576d868850312d6c14d1386f8fbfa85021b347 An earlier design used PTRACE_SINGLESTEP with libunwind's remote unwinding features. ptrace is a mess around stop signals (see group-stop discussion in ptrace(2)) and this is 10x faster, so I went with it. The question of which is more future-proof is complex: - There are two libunwinds with the same API, https://www.nongnu.org/libunwind/ and LLVM's. This currently uses the system nongnu.org for convenience. In future, LLVM's should be easier to bundle (less complex build) and appears to even support Windows, but I haven't tested this. Moreover, setting the trap flag keeps the test single-process, which is less complex on Windows. That suggests the trap flag design and switching to LLVM later. However... - Not all architectures have a trap flag settable by userspace. As far as I can tell, ARMv8's PSTATE.SS can only be set from the kernel. If we stick with nongnu.org libunwind, we can use PTRACE_SINGLESTEP and remote unwinding. Or we implement it for LLVM. Another thought is for the ptracer to bounce SIGTRAP back into the process, to share the local unwinding code. - ARMv7 has no trap flag at all and PTRACE_SINGLESTEP fails. Debuggers single-step by injecting breakpoints instead. However, ARMv8's trap flag seems to work in both AArch32 and AArch64 modes, so we may be able to condition it on a 64-bit kernel. Sadly, neither strategy works with Intel SDE. Adding flags to cpucap vectors as we do with ARM would help, but it would not emulate CPUs newer than the host CPU. For now, I've just had SDE tests disable these. Annoyingly, CMake does not allow object libraries to have dependencies, so make test_support a proper static library. Rename the target to test_support_lib to avoid https://gitlab.kitware.com/cmake/cmake/issues/17785 Update-Note: This adds a new optional test dependency, but it's disabled by default (define BORINGSSL_HAVE_LIBUNWIND), so consumers do not need to do anything. We'll probably want to adjust this in the future. Bug: 181 Change-Id: I817263d7907aff0904a9cee83f8b26747262cc0c Reviewed-on: https://boringssl-review.googlesource.com/c/33966 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-12-21 23:58:36 +00:00
else()
Make pkg-config optional. Since libunwind, and therefore the CFI tests, are already optional, might as well make pkg-config optional too. (I'm not sure whether we actually want to support people using our development build, but gRPC appear to be trying to do so: https://github.com/grpc/grpc/issues/17638) Change-Id: I16b4c53bd8a66933bc19fba29aed0d79ce2670c2 Reviewed-on: https://boringssl-review.googlesource.com/c/34124 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2019-01-04 15:53:25 +00:00
message("pkgconfig not found. Disabling unwind tests.")
Add a CFI tester to CHECK_ABI. This uses the x86 trap flag and libunwind to test CFI works at each instruction. For now, it just uses the system one out of pkg-config and disables unwind tests if unavailable. We'll probably want to stick a copy into //third_party and perhaps try the LLVM one later. This tester caught two bugs in P-256 CFI annotations already: I47b5f9798b3bcee1748e537b21c173d312a14b42 and I9f576d868850312d6c14d1386f8fbfa85021b347 An earlier design used PTRACE_SINGLESTEP with libunwind's remote unwinding features. ptrace is a mess around stop signals (see group-stop discussion in ptrace(2)) and this is 10x faster, so I went with it. The question of which is more future-proof is complex: - There are two libunwinds with the same API, https://www.nongnu.org/libunwind/ and LLVM's. This currently uses the system nongnu.org for convenience. In future, LLVM's should be easier to bundle (less complex build) and appears to even support Windows, but I haven't tested this. Moreover, setting the trap flag keeps the test single-process, which is less complex on Windows. That suggests the trap flag design and switching to LLVM later. However... - Not all architectures have a trap flag settable by userspace. As far as I can tell, ARMv8's PSTATE.SS can only be set from the kernel. If we stick with nongnu.org libunwind, we can use PTRACE_SINGLESTEP and remote unwinding. Or we implement it for LLVM. Another thought is for the ptracer to bounce SIGTRAP back into the process, to share the local unwinding code. - ARMv7 has no trap flag at all and PTRACE_SINGLESTEP fails. Debuggers single-step by injecting breakpoints instead. However, ARMv8's trap flag seems to work in both AArch32 and AArch64 modes, so we may be able to condition it on a 64-bit kernel. Sadly, neither strategy works with Intel SDE. Adding flags to cpucap vectors as we do with ARM would help, but it would not emulate CPUs newer than the host CPU. For now, I've just had SDE tests disable these. Annoyingly, CMake does not allow object libraries to have dependencies, so make test_support a proper static library. Rename the target to test_support_lib to avoid https://gitlab.kitware.com/cmake/cmake/issues/17785 Update-Note: This adds a new optional test dependency, but it's disabled by default (define BORINGSSL_HAVE_LIBUNWIND), so consumers do not need to do anything. We'll probably want to adjust this in the future. Bug: 181 Change-Id: I817263d7907aff0904a9cee83f8b26747262cc0c Reviewed-on: https://boringssl-review.googlesource.com/c/33966 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-12-21 23:58:36 +00:00
endif()
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(NOT GO_EXECUTABLE)
Generate error data at build time. This avoids cluttering up the diff and making merge conflicts a pain. It does, however, mean we need to generate err_data.c ahead of time in Chromium and likely other downstream builds. It also adds a build dependency on Go. Change-Id: I6e0513ed9f50cfb030f7a523ea28519590977104 Reviewed-on: https://boringssl-review.googlesource.com/3790 Reviewed-by: Adam Langley <agl@google.com>
2015-03-05 06:19:27 +00:00
message(FATAL_ERROR "Could not find Go")
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(USE_CUSTOM_LIBCXX)
Add an option to statically link a custom libc++. MSan and TSan both require instrumenting everything. Add some machinery so we can do this on the bots. Change-Id: I7d2106bc852ee976455d18787d3a20a35373a9e7 Reviewed-on: https://boringssl-review.googlesource.com/30644 Reviewed-by: Adam Langley <agl@google.com>
2018-08-09 21:33:07 +01:00
set(BORINGSSL_ALLOW_CXX_RUNTIME 1)
endif()
Support symbol prefixes - In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(BORINGSSL_ALLOW_CXX_RUNTIME)
Add a CMake toggle to allow the C++ runtime. In particular, this removes -fno-rtti, which allows the OSS-Fuzz folks to run with -fsanitize=vptr. See https://github.com/google/oss-fuzz/issues/741. (-fsanitize=vptr isn't especially useful right now as we're just starting with C++ support, but perhaps it'll be more useful in the future.) Change-Id: Ie8944a3e637ebc8dc28c03d331923a7528d7d328 Reviewed-on: https://boringssl-review.googlesource.com/18484 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-07-26 16:39:38 +01:00
add_definitions(-DBORINGSSL_ALLOW_CXX_RUNTIME)
endif()
Add test of assembly code dispatch. The first attempt involved using Linux's support for hardware breakpoints to detect when assembly code was run. However, this doesn't work with SDE, which is a problem. This version has the assembly code update a global flags variable when it's run, but only in non-FIPS and non-debug builds. Update-Note: Assembly files now pay attention to the NDEBUG preprocessor symbol. Ensure the build passes the symbol in. (If release builds fail to link due to missing BORINGSSL_function_hit, this is the cause.) Change-Id: I6b7ced442b7a77d0b4ae148b00c351f68af89a6e Reviewed-on: https://boringssl-review.googlesource.com/c/33384 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2018-11-27 22:07:12 +00:00
if(CMAKE_BUILD_TYPE STREQUAL "Release")
# Windows release builds don't set NDEBUG in NASM flags automatically.
set(CMAKE_ASM_NASM_FLAGS "${CMAKE_ASM_NASM_FLAGS} -DNDEBUG")
endif()
Add a RelWithAsserts build configuration. On our bots, debug unit tests take around 2.5x as long to complete as release tests on Linux, 3x as long on macOS, and 6x as long on Windows. Our tests are fast, so this does not particularly matter, but SDE inflates a 13 second test run to 8 minutes. On Windows (MSVC), where we don't but would like to test with SDE, the difference between optimized and unoptimized is even larger, and test runs are slower in general. This suggests running SDE tests in release mode. Release mode tests, however, are less effective because they do not include asserts. Thus, add a RelWithAsserts option. (Chromium does something similar. I believe most of the test-running configurations on the critical path run is_debug = false and dcheck_always_on = true.) Change-Id: I273dd86ab8ea039f34eca431483827c87dc5c461 Reviewed-on: https://boringssl-review.googlesource.com/c/34464 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-01-23 01:49:35 +00:00
# Add a RelWithAsserts build configuration. It is the same as Release, except it
# does not define NDEBUG, so asserts run.
foreach(VAR CMAKE_C_FLAGS CMAKE_CXX_FLAGS CMAKE_ASM_FLAGS)
string(REGEX REPLACE "(^| )[/-]DNDEBUG( |$)" " " "${VAR}_RELWITHASSERTS"
"${${VAR}_RELEASE}")
endforeach()
Support symbol prefixes - In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
if(BORINGSSL_PREFIX AND BORINGSSL_PREFIX_SYMBOLS)
add_definitions(-DBORINGSSL_PREFIX=${BORINGSSL_PREFIX})
Make Windows symbol-prefixing work. This teaches read_symbols.go to use debug/pe, and fixes miscellaneous issues with NASM. It also reveals a problem with this strategy of getting symbols out at the linker level: inline functions. I'm thinking a better long-term mechanism may be to parse our header files. Change-Id: I11b008543a7a97db3db9d4062ee4ddb910d174b7 Reviewed-on: https://boringssl-review.googlesource.com/c/33349 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-11-25 21:58:02 +00:00
# CMake automatically connects include_directories to the NASM command-line,
# but not add_definitions.
set(CMAKE_ASM_NASM_FLAGS "${CMAKE_ASM_NASM_FLAGS} -DBORINGSSL_PREFIX=${BORINGSSL_PREFIX}")
Support symbol prefixes - In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
# Use "symbol_prefix_include" to store generated header files
include_directories(${CMAKE_CURRENT_BINARY_DIR}/symbol_prefix_include)
add_custom_command(
OUTPUT symbol_prefix_include/boringssl_prefix_symbols.h
symbol_prefix_include/boringssl_prefix_symbols_asm.h
symbol_prefix_include/boringssl_prefix_symbols_nasm.inc
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/symbol_prefix_include
COMMAND ${GO_EXECUTABLE} run ${CMAKE_CURRENT_SOURCE_DIR}/util/make_prefix_headers.go -out ${CMAKE_CURRENT_BINARY_DIR}/symbol_prefix_include ${BORINGSSL_PREFIX_SYMBOLS}
DEPENDS util/make_prefix_headers.go
${CMAKE_BINARY_DIR}/${BORINGSSL_PREFIX_SYMBOLS})
# add_dependencies needs a target, not a file, so we add an intermediate
# target.
add_custom_target(
boringssl_prefix_symbols
DEPENDS symbol_prefix_include/boringssl_prefix_symbols.h
symbol_prefix_include/boringssl_prefix_symbols_asm.h
symbol_prefix_include/boringssl_prefix_symbols_nasm.inc)
add_dependencies(global_target boringssl_prefix_symbols)
elseif(BORINGSSL_PREFIX OR BORINGSSL_PREFIX_SYMBOLS)
message(FATAL_ERROR "Must specify both or neither of BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS")
endif()
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
set(CLANG 1)
endif()
if(CMAKE_COMPILER_IS_GNUCXX OR CLANG)
# Note clang-cl is odd and sets both CLANG and MSVC. We base our configuration
Update tools. This is a reland 9d1f96606cd7af3b8d441fbc5e8d2e69da37c506, which should hopefuly be fine after afd1cd959e75eb8f62fcfc6b1c1124537a09b2f9. Though I've also gone ahead and gotten the latest versions of things. (android_tools and clang updated.) In particular, get the new NDK. Unfortunately, the new clang picks up an unfortunate change for clang-cl that we now must work around. http://llvm.org/viewvc/llvm-project?view=revision&revision=319116 Bug: 109 Change-Id: If19b09c585957fefaffa8c3197a50189402a555a Reviewed-on: https://boringssl-review.googlesource.com/25025 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-01-05 20:43:09 +00:00
# primarily on our normal Clang one.
set(C_CXX_FLAGS "-Werror -Wformat=2 -Wsign-compare -Wmissing-field-initializers -Wwrite-strings")
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(MSVC)
Update tools. This is a reland 9d1f96606cd7af3b8d441fbc5e8d2e69da37c506, which should hopefuly be fine after afd1cd959e75eb8f62fcfc6b1c1124537a09b2f9. Though I've also gone ahead and gotten the latest versions of things. (android_tools and clang updated.) In particular, get the new NDK. Unfortunately, the new clang picks up an unfortunate change for clang-cl that we now must work around. http://llvm.org/viewvc/llvm-project?view=revision&revision=319116 Bug: 109 Change-Id: If19b09c585957fefaffa8c3197a50189402a555a Reviewed-on: https://boringssl-review.googlesource.com/25025 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-01-05 20:43:09 +00:00
# clang-cl sets different default warnings than clang. It also treats -Wall
# as -Weverything, to match MSVC. Instead -W3 is the alias for -Wall.
# See http://llvm.org/viewvc/llvm-project?view=revision&revision=319116
set(C_CXX_FLAGS "${C_CXX_FLAGS} -W3 -Wno-unused-parameter -fmsc-version=1900")
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
# googletest suppresses warning C4996 via a pragma, but clang-cl does not
# honor it. Suppress it here to compensate. See https://crbug.com/772117.
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wno-deprecated-declarations")
else()
Update tools. This is a reland 9d1f96606cd7af3b8d441fbc5e8d2e69da37c506, which should hopefuly be fine after afd1cd959e75eb8f62fcfc6b1c1124537a09b2f9. Though I've also gone ahead and gotten the latest versions of things. (android_tools and clang updated.) In particular, get the new NDK. Unfortunately, the new clang picks up an unfortunate change for clang-cl that we now must work around. http://llvm.org/viewvc/llvm-project?view=revision&revision=319116 Bug: 109 Change-Id: If19b09c585957fefaffa8c3197a50189402a555a Reviewed-on: https://boringssl-review.googlesource.com/25025 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-01-05 20:43:09 +00:00
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wall -ggdb -fvisibility=hidden -fno-common")
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
endif()
Explicit fallthrough on switch Fixes failed compile with [-Werror=implicit-fallthrough=], which is default on gcc-7.x on distributions like fedora. Enabling no implicit fallthrough for more than just clang as well to catch this going forward. Change-Id: I6cd880dac70ec126bd7812e2d9e5ff804d32cadd Signed-off-by: Vincent Batts <vbatts@redhat.com> Reviewed-on: https://boringssl-review.googlesource.com/20564 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2017-09-20 16:51:54 +01:00
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(CLANG)
Turn on clang -fcolor-diagnostics. I'm not sure why these aren't on by default, but Chromium does this too. Colors are nice. Change-Id: I7d7bf006014e9f40ec2f48290ad8fe7a70c1cfce Reviewed-on: https://boringssl-review.googlesource.com/18704 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2017-07-31 19:03:38 +01:00
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wnewline-eof -fcolor-diagnostics")
Move bn/ into crypto/fipsmodule/ Change-Id: I68aa4a740ee1c7f2a308a6536f408929f15b694c Reviewed-on: https://boringssl-review.googlesource.com/15647 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-28 22:47:06 +01:00
else()
# GCC (at least 4.8.4) has a bug where it'll find unreachable free() calls
# and declare that the code is trying to free a stack pointer.
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wno-free-nonheap-object")
Be -Wnewline-eof clean. Change-Id: I85216184f9277ce0c0caae31e379b638683e28c5 Reviewed-on: https://boringssl-review.googlesource.com/10703 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-08-29 19:59:31 +01:00
endif()
Explicit fallthrough on switch Fixes failed compile with [-Werror=implicit-fallthrough=], which is default on gcc-7.x on distributions like fedora. Enabling no implicit fallthrough for more than just clang as well to catch this going forward. Change-Id: I6cd880dac70ec126bd7812e2d9e5ff804d32cadd Signed-off-by: Vincent Batts <vbatts@redhat.com> Reviewed-on: https://boringssl-review.googlesource.com/20564 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2017-09-20 16:51:54 +01:00
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(CLANG OR NOT "7.0.0" VERSION_GREATER CMAKE_C_COMPILER_VERSION)
Explicit fallthrough on switch Fixes failed compile with [-Werror=implicit-fallthrough=], which is default on gcc-7.x on distributions like fedora. Enabling no implicit fallthrough for more than just clang as well to catch this going forward. Change-Id: I6cd880dac70ec126bd7812e2d9e5ff804d32cadd Signed-off-by: Vincent Batts <vbatts@redhat.com> Reviewed-on: https://boringssl-review.googlesource.com/20564 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2017-09-20 16:51:54 +01:00
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wimplicit-fallthrough")
endif()
Add top-level BUILD file (in util/). When we have *-with-bazel branches this BUILD file will be copied to the top-level for consumers that want to use Bazel. From empirical testing, x86-64 on Linux is spelt “k8” and x86-64 on macOS is spelt “darwin”. I've not tried to enable assembly for any other cases yet. Change-Id: Ic6cb739565f145db20756fb57c0d087227fd9e18 Reviewed-on: https://boringssl-review.googlesource.com/8571 Reviewed-by: Adam Langley <agl@google.com>
2016-06-30 22:16:59 +01:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${C_CXX_FLAGS} -Wmissing-prototypes -Wold-style-definition -Wstrict-prototypes")
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${C_CXX_FLAGS} -Wmissing-declarations")
Add a CMake toggle to allow the C++ runtime. In particular, this removes -fno-rtti, which allows the OSS-Fuzz folks to run with -fsanitize=vptr. See https://github.com/google/oss-fuzz/issues/741. (-fsanitize=vptr isn't especially useful right now as we're just starting with C++ support, but perhaps it'll be more useful in the future.) Change-Id: Ie8944a3e637ebc8dc28c03d331923a7528d7d328 Reviewed-on: https://boringssl-review.googlesource.com/18484 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-07-26 16:39:38 +01:00
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(NOT MSVC)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
Specify -stdlib=libc++ if APPLE If you specify any --target which refers to a x86_64-apple-darwin triple, or a more specific variant derived from it, specifying -stdlib=libc++ is required, otherwise clang falls back to libstdc++ which didn't include c++11, and fails to compile in very obscure ways (simply failing to find any c++11 symbols). Change-Id: I58025cea91eaa0c16d9b5831f9965889b75bbc31 Reviewed-on: https://boringssl-review.googlesource.com/21984 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-16 20:58:08 +01:00
if(APPLE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
endif()
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(NOT BORINGSSL_ALLOW_CXX_RUNTIME)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions -fno-rtti")
endif()
Add a CMake toggle to allow the C++ runtime. In particular, this removes -fno-rtti, which allows the OSS-Fuzz folks to run with -fsanitize=vptr. See https://github.com/google/oss-fuzz/issues/741. (-fsanitize=vptr isn't especially useful right now as we're just starting with C++ support, but perhaps it'll be more useful in the future.) Change-Id: Ie8944a3e637ebc8dc28c03d331923a7528d7d328 Reviewed-on: https://boringssl-review.googlesource.com/18484 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-07-26 16:39:38 +01:00
endif()
Make missing prototypes warning work in clang/C++. in GCC, -Wmissing-prototypes is only in C and the C++ spelling is -Wmissing-declarations. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options In clang, -Wmissing-prototypes is in both C/C++ and -Wmissing-declarations means you forgot to name a typedef or something? https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-prototypes https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-declarations Pass clang slightly different flags to account for this mess. Change-Id: I574ff7ecf32ba5908355639de83e8a102dab5f04 Reviewed-on: https://boringssl-review.googlesource.com/17784 Reviewed-by: Steven Valdez <svaldez@google.com>
2017-07-13 22:53:07 +01:00
# In GCC, -Wmissing-declarations is the C++ spelling of -Wmissing-prototypes
# and using the wrong one is an error. In Clang, -Wmissing-prototypes is the
# spelling for both and -Wmissing-declarations is some other warning.
#
# https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options
# https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-prototypes
# https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-declarations
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(CLANG)
Explicit fallthrough on switch Fixes failed compile with [-Werror=implicit-fallthrough=], which is default on gcc-7.x on distributions like fedora. Enabling no implicit fallthrough for more than just clang as well to catch this going forward. Change-Id: I6cd880dac70ec126bd7812e2d9e5ff804d32cadd Signed-off-by: Vincent Batts <vbatts@redhat.com> Reviewed-on: https://boringssl-review.googlesource.com/20564 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2017-09-20 16:51:54 +01:00
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wmissing-prototypes")
Make missing prototypes warning work in clang/C++. in GCC, -Wmissing-prototypes is only in C and the C++ spelling is -Wmissing-declarations. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options In clang, -Wmissing-prototypes is in both C/C++ and -Wmissing-declarations means you forgot to name a typedef or something? https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-prototypes https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-declarations Pass clang slightly different flags to account for this mess. Change-Id: I574ff7ecf32ba5908355639de83e8a102dab5f04 Reviewed-on: https://boringssl-review.googlesource.com/17784 Reviewed-by: Steven Valdez <svaldez@google.com>
2017-07-13 22:53:07 +01:00
endif()
Set -Wno-array-bounds on gcc<4.8 It spuriously complains about pointer math on function arguments which are arrays. Change-Id: I23b3494740196d5d46ce525a32dd43782e77f0ce Reviewed-on: https://boringssl-review.googlesource.com/21404 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-09 20:09:43 +01:00
if(CMAKE_COMPILER_IS_GNUCXX AND "4.8" VERSION_GREATER CMAKE_C_COMPILER_VERSION)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-array-bounds")
endif()
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
elseif(MSVC)
Enable more warnings & treat warnings as errors on Windows. Change-Id: I2bf0144aaa8b670ff00b8e8dfe36bd4d237b9a8a Reviewed-on: https://boringssl-review.googlesource.com/3140 Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 00:20:02 +00:00
set(MSVC_DISABLED_WARNINGS_LIST
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
"C4061" # enumerator 'identifier' in switch of enum 'enumeration' is not
# explicitly handled by a case label
# Disable this because it flags even when there is a default.
Enable more warnings & treat warnings as errors on Windows. Change-Id: I2bf0144aaa8b670ff00b8e8dfe36bd4d237b9a8a Reviewed-on: https://boringssl-review.googlesource.com/3140 Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 00:20:02 +00:00
"C4100" # 'exarg' : unreferenced formal parameter
"C4127" # conditional expression is constant
"C4200" # nonstandard extension used : zero-sized array in
# struct/union.
Add a helper function for parsing extensions blocks. TLS 1.3 adds a number of places with extensions blocks that don't easily fit into our ClientHello/EncryptedExtensions callbacks. Between HelloRetryRequest, ServerHello, draft 18 going nuts with Certificate, and NewSessionTicket when we do 0-RTT, this passes the "abstract things that are repeated three times" sniff test. For now, it rejects unknown extensions, but it will probably grow an allow_unknown parameter for NewSessionTicket. This involves disabling some MSVC warnings, but they're invalid as of C99 which we otherwise require. See https://connect.microsoft.com/VisualStudio/feedback/details/1230248/remove-c99-related-warnings-or-make-them-off-by-default Change-Id: Iea8bf8ab216270c081dd63e79aaad9ec73b3b550 Reviewed-on: https://boringssl-review.googlesource.com/12233 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-11-13 01:32:10 +00:00
"C4204" # nonstandard extension used: non-constant aggregate initializer
"C4221" # nonstandard extension used : 'identifier' : cannot be
# initialized using address of automatic variable
Enable more warnings & treat warnings as errors on Windows. Change-Id: I2bf0144aaa8b670ff00b8e8dfe36bd4d237b9a8a Reviewed-on: https://boringssl-review.googlesource.com/3140 Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 00:20:02 +00:00
"C4242" # 'function' : conversion from 'int' to 'uint8_t',
# possible loss of data
"C4244" # 'function' : conversion from 'int' to 'uint8_t',
# possible loss of data
Fix standalone build on Win64. Win64 fires significantly more warnings than Win32. Also some recent changes made it grumpy. (We might want to reconsider enabling all of MSVC's warnings. Given the sorts of warnings some of these are, I'm not sure MSVC's version of -Wall -Werror is actually tenable. Plus, diverging from the Chromium build, especially before the bots are ready, is going to break pretty readily.) Change-Id: If3b8feccf910ceab4a233b0731e7624d7da46f87 Reviewed-on: https://boringssl-review.googlesource.com/3420 Reviewed-by: Adam Langley <agl@google.com>
2015-02-11 20:12:05 +00:00
"C4267" # conversion from 'size_t' to 'int', possible loss of data
"C4371" # layout of class may have changed from a previous version of the
# compiler due to better packing of member '...'
"C4388" # signed/unsigned mismatch
Enable more warnings & treat warnings as errors on Windows. Change-Id: I2bf0144aaa8b670ff00b8e8dfe36bd4d237b9a8a Reviewed-on: https://boringssl-review.googlesource.com/3140 Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 00:20:02 +00:00
"C4296" # '>=' : expression is always true
"C4350" # behavior change: 'std::_Wrap_alloc...'
"C4365" # '=' : conversion from 'size_t' to 'int',
# signed/unsigned mismatch
"C4389" # '!=' : signed/unsigned mismatch
Start assuming MSVC 2015. BUG=43 Change-Id: I46ad1ca62b8921a03fae51f5d7bbe1c68fc0b170 Reviewed-on: https://boringssl-review.googlesource.com/7821 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-05-02 17:57:01 +01:00
"C4464" # relative include path contains '..'
Enable more warnings & treat warnings as errors on Windows. Change-Id: I2bf0144aaa8b670ff00b8e8dfe36bd4d237b9a8a Reviewed-on: https://boringssl-review.googlesource.com/3140 Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 00:20:02 +00:00
"C4510" # 'argument' : default constructor could not be generated
"C4512" # 'argument' : assignment operator could not be generated
"C4514" # 'function': unreferenced inline function has been removed
"C4548" # expression before comma has no effect; expected expression with
# side-effect" caused by FD_* macros.
"C4610" # struct 'argument' can never be instantiated - user defined
# constructor required.
Start assuming MSVC 2015. BUG=43 Change-Id: I46ad1ca62b8921a03fae51f5d7bbe1c68fc0b170 Reviewed-on: https://boringssl-review.googlesource.com/7821 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-05-02 17:57:01 +01:00
"C4623" # default constructor was implicitly defined as deleted
Fix standalone build on Win64. Win64 fires significantly more warnings than Win32. Also some recent changes made it grumpy. (We might want to reconsider enabling all of MSVC's warnings. Given the sorts of warnings some of these are, I'm not sure MSVC's version of -Wall -Werror is actually tenable. Plus, diverging from the Chromium build, especially before the bots are ready, is going to break pretty readily.) Change-Id: If3b8feccf910ceab4a233b0731e7624d7da46f87 Reviewed-on: https://boringssl-review.googlesource.com/3420 Reviewed-by: Adam Langley <agl@google.com>
2015-02-11 20:12:05 +00:00
"C4625" # copy constructor could not be generated because a base class
# copy constructor is inaccessible or deleted
"C4626" # assignment operator could not be generated because a base class
# assignment operator is inaccessible or deleted
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
"C4668" # 'symbol' is not defined as a preprocessor macro, replacing with
# '0' for 'directives'
# Disable this because GTest uses it everywhere.
Enable more warnings & treat warnings as errors on Windows. Change-Id: I2bf0144aaa8b670ff00b8e8dfe36bd4d237b9a8a Reviewed-on: https://boringssl-review.googlesource.com/3140 Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 00:20:02 +00:00
"C4706" # assignment within conditional expression
"C4710" # 'function': function not inlined
"C4711" # function 'function' selected for inline expansion
"C4800" # 'int' : forcing value to bool 'true' or 'false'
# (performance warning)
"C4820" # 'bytes' bytes padding added after construct 'member_name'
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
"C5026" # move constructor was implicitly defined as deleted
Start assuming MSVC 2015. BUG=43 Change-Id: I46ad1ca62b8921a03fae51f5d7bbe1c68fc0b170 Reviewed-on: https://boringssl-review.googlesource.com/7821 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-05-02 17:57:01 +01:00
"C5027" # move assignment operator was implicitly defined as deleted
Ignore Spectre mitigation warning. VS2017 has added a new warning that indicates where Spectre mitigation code would be inserted if /Qspectre were specified. Change-Id: If80cd6a7d0c5a45313f4c3644b304cadecf465b0 Reviewed-on: https://boringssl-review.googlesource.com/28684 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-05-22 13:50:44 +01:00
"C5045" # Compiler will insert Spectre mitigation for memory load if
# /Qspectre switch specified
Start assuming MSVC 2015. BUG=43 Change-Id: I46ad1ca62b8921a03fae51f5d7bbe1c68fc0b170 Reviewed-on: https://boringssl-review.googlesource.com/7821 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-05-02 17:57:01 +01:00
)
set(MSVC_LEVEL4_WARNINGS_LIST
# See https://connect.microsoft.com/VisualStudio/feedback/details/1217660/warning-c4265-when-using-functional-header
"C4265" # class has virtual functions, but destructor is not virtual
)
Enable more warnings & treat warnings as errors on Windows. Change-Id: I2bf0144aaa8b670ff00b8e8dfe36bd4d237b9a8a Reviewed-on: https://boringssl-review.googlesource.com/3140 Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 00:20:02 +00:00
string(REPLACE "C" " -wd" MSVC_DISABLED_WARNINGS_STR
${MSVC_DISABLED_WARNINGS_LIST})
Start assuming MSVC 2015. BUG=43 Change-Id: I46ad1ca62b8921a03fae51f5d7bbe1c68fc0b170 Reviewed-on: https://boringssl-review.googlesource.com/7821 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-05-02 17:57:01 +01:00
string(REPLACE "C" " -w4" MSVC_LEVEL4_WARNINGS_STR
${MSVC_LEVEL4_WARNINGS_LIST})
fix compilation error for non-english windows (like cjk) add /utf-8 switch for msvc build. source code has several utf-8 characters fix C2001 error. escape non-printable ascii code generated by embed_test_data.go fix C4819 warning. add u8 keyword on utf-8 string literal (ripemd_test.cc) Change-Id: I8c04dc7f0359e6ee27efada066863826d263d5cd Reviewed-on: https://boringssl-review.googlesource.com/26484 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-03-11 10:20:51 +00:00
set(CMAKE_C_FLAGS "-utf-8 -Wall -WX ${MSVC_DISABLED_WARNINGS_STR} ${MSVC_LEVEL4_WARNINGS_STR}")
set(CMAKE_CXX_FLAGS "-utf-8 -Wall -WX ${MSVC_DISABLED_WARNINGS_STR} ${MSVC_LEVEL4_WARNINGS_STR}")
Tidy up some Windows compiler assumptions. Someone tried to build us with Ubuntu's MinGW. This is too old to be supported (the tests rather badly fail to build), but some of the fixes will likely be useful for eventually building Clang for Windows standalone too. Change-Id: I6d279a0da1346b4e0813de51df3373b7412de33a Reviewed-on: https://boringssl-review.googlesource.com/19364 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-16 20:25:27 +01:00
endif()
if(WIN32)
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
add_definitions(-D_HAS_EXCEPTIONS=0)
Define WIN32_LEAN_AND_MEAN in the build system, not in the code. This avoids a conflict with the Chromium build system, which defines WIN32_LEAN_AND_MEAN with a different value. BUG=crbug.com/453196 Change-Id: Ia15ec7c20325c1961af4f32e5208266e5f846f35 Reviewed-on: https://boringssl-review.googlesource.com/3150 Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-01-29 04:34:47 +00:00
add_definitions(-DWIN32_LEAN_AND_MEAN)
Define NOMINMAX across the entire project. This fixes the standalone build on Windows and matches Chromium. Change-Id: I194f53e0a610c5ae9cef53c826b22f7bded5f357 Reviewed-on: https://boringssl-review.googlesource.com/4201 Reviewed-by: Adam Langley <agl@google.com>
2015-04-02 18:20:01 +01:00
add_definitions(-DNOMINMAX)
Use _STL_EXTRA_DISABLED_WARNINGS in VS2017. Although Microsoft does not support building with /Wall, starting VS2017, they provide a way to suppress warnings only in STL code. This lets us keep some warnings active on our code while disabling them in the STL. https://blogs.msdn.microsoft.com/vcblog/2017/02/06/stl-fixes-in-vs-2017-rtm/ We currently still support VS2015, so we can't switch most of our suppressions to this, but anything which applies only to VS2017 and up will work. Change-Id: I5f6d621dd1dbc060e09bded776d1714785a63147 Reviewed-on: https://boringssl-review.googlesource.com/17245 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-06-16 01:44:30 +01:00
# Allow use of fopen.
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
Fix VS build when assembler is enabled The whitespace in the _STL_EXTRA_DISABLED_WARNINGS value was creating issues for the CMake generated assembler build script called by VS. By narrowing the build scope of this STL (and thus C++ only) variable to only C++ we avoid the problem altogether as it will not be passed to the assembler script. Change-Id: Id422bdd991492f39acc82d52af2ea6d952deb6c6 Reviewed-on: https://boringssl-review.googlesource.com/29504 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-06-29 18:44:36 +01:00
# VS 2017 and higher supports STL-only warning suppressions. Manually add to
# C++ only to work around a CMake quoting bug when using NASM with the Visual
Add link to CMake bugfix. Change-Id: I6d82cbb33a5ac2acf3f4e0993210e0bddba8f1ad Reviewed-on: https://boringssl-review.googlesource.com/29644 Reviewed-by: Adam Langley <agl@google.com>
2018-07-06 19:46:30 +01:00
# Studio generator. This will be fixed in CMake 3.13.0. See
# https://gitlab.kitware.com/cmake/cmake/merge_requests/2179
Fix VS build when assembler is enabled The whitespace in the _STL_EXTRA_DISABLED_WARNINGS value was creating issues for the CMake generated assembler build script called by VS. By narrowing the build scope of this STL (and thus C++ only) variable to only C++ we avoid the problem altogether as it will not be passed to the assembler script. Change-Id: Id422bdd991492f39acc82d52af2ea6d952deb6c6 Reviewed-on: https://boringssl-review.googlesource.com/29504 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-06-29 18:44:36 +01:00
add_compile_options($<$<COMPILE_LANGUAGE:CXX>:-D_STL_EXTRA_DISABLED_WARNINGS=4774\ 4987>)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
endif()
Bump the -Wshadow cutoff to 4.8 rather than 4.6. Per https://gcc.gnu.org/gcc-4.8/changes.html, -Wshadow was made less trigger-happy starting 4.8. Change-Id: I023919dea3497e2dd27679a6f0c4a114c0b30337 Reviewed-on: https://boringssl-review.googlesource.com/3730 Reviewed-by: Adam Langley <agl@google.com>
2015-02-28 05:00:44 +00:00
if((CMAKE_COMPILER_IS_GNUCXX AND CMAKE_C_COMPILER_VERSION VERSION_GREATER "4.7.99") OR
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
CLANG)
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wshadow")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wshadow")
Only use -Wshadow with GCC > 4.6.0. Prior to 4.6.0, -Wshadow would cause GCC to warn when variables shadowed global functions. Since libc defines a number of functions with common names, this is a problem. Also, without this change, we'll keep breaking on older versions of GCC because we won't be testing with them. OpenBSD, specifically is reported to have a problem: https://boringssl-review.googlesource.com/#/c/2900/ (Note the test should really be >= 4.6.0, but CMake doesn't have a VERSION_GREATEROREQUAL.) Change-Id: I1aedda01ab629e138c8781e4319bfaaed0b236b0 Reviewed-on: https://boringssl-review.googlesource.com/2952 Reviewed-by: Adam Langley <agl@google.com>
2015-01-16 23:20:54 +00:00
endif()
Use one C99-style for loop. Switch one for loop to the new spelling as a canary. All our compilers seem to support it fine, except GCC needs to be told to build with -std=c99. (And, upon doing so, it'll require _XOPEN_SOURCE=700 for pthread_rwlock_t.) We'll let this sit for a bit until it's gotten into downstreams without issue and then open the floodgates. BUG=47 Change-Id: I1c69d4b2df8206e0b55f30aa59b5874d82fca893 Reviewed-on: https://boringssl-review.googlesource.com/8235 Reviewed-by: Adam Langley <agl@google.com>
2016-06-09 21:22:26 +01:00
if(CMAKE_COMPILER_IS_GNUCXX)
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if((CMAKE_C_COMPILER_VERSION VERSION_GREATER "4.8.99") OR CLANG)
Use one C99-style for loop. Switch one for loop to the new spelling as a canary. All our compilers seem to support it fine, except GCC needs to be told to build with -std=c99. (And, upon doing so, it'll require _XOPEN_SOURCE=700 for pthread_rwlock_t.) We'll let this sit for a bit until it's gotten into downstreams without issue and then open the floodgates. BUG=47 Change-Id: I1c69d4b2df8206e0b55f30aa59b5874d82fca893 Reviewed-on: https://boringssl-review.googlesource.com/8235 Reviewed-by: Adam Langley <agl@google.com>
2016-06-09 21:22:26 +01:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c11")
else()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
endif()
endif()
# pthread_rwlock_t requires a feature flag.
if(NOT WIN32)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_XOPEN_SOURCE=700")
Add infrastructure for reference counts. OpenSSL has traditionally done reference counting with |int|s and the |CRYPTO_add| function. Unless a special callback is installed (rare), this is implemented by doing the reference count operations under a lock. This change adds infrastructure for handling reference counts and uses atomic operations when C11 support is available. Change-Id: Ia023ce432319efd00f77a7340da27d16ee4b63c3 Reviewed-on: https://boringssl-review.googlesource.com/4771 Reviewed-by: Adam Langley <agl@google.com>
2015-05-15 20:01:29 +01:00
endif()
Add four, basic fuzz tests. This change adds fuzzing tests for: ∙ Certificate parsing ∙ Private key parsing ∙ ClientHello parsing ∙ Server first flow (ServerHello, Certificate, etc) parsing. Change-Id: I5f53282263eaaff69b1a03c819cca73750433653 Reviewed-on: https://boringssl-review.googlesource.com/6460 Reviewed-by: Adam Langley <agl@google.com>
2015-11-09 21:57:26 +00:00
if(FUZZ)
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(NOT CLANG)
Fix CMake negation and make error fatal Not sure if version-dependant, but with CMake 3.6 "!" doesn't work. Change-Id: I5f91234b27e340142b479b602d4102134ad55ccb Reviewed-on: https://boringssl-review.googlesource.com/11381 Reviewed-by: Adam Langley <agl@google.com>
2016-09-28 22:14:01 +01:00
message(FATAL_ERROR "You need to build with Clang for fuzzing to work")
Add four, basic fuzz tests. This change adds fuzzing tests for: ∙ Certificate parsing ∙ Private key parsing ∙ ClientHello parsing ∙ Server first flow (ServerHello, Certificate, etc) parsing. Change-Id: I5f53282263eaaff69b1a03c819cca73750433653 Reviewed-on: https://boringssl-review.googlesource.com/6460 Reviewed-by: Adam Langley <agl@google.com>
2015-11-09 21:57:26 +00:00
endif()
Switch to Clang 6.0's fuzzer support. With Clang 6.0, libFuzzer is now included and there's a new -fsanitize=fuzzer command to enable the needed compiler actions. Change-Id: If8c0d649f494655c5bb1e55ebdbf39450940c75b Reviewed-on: https://boringssl-review.googlesource.com/31324 Reviewed-by: David Benjamin <davidben@google.com>
2018-08-24 18:46:01 +01:00
if(CMAKE_C_COMPILER_VERSION VERSION_LESS "6.0.0")
message(FATAL_ERROR "You need Clang ≥ 6.0.0")
endif()
Add corpora for fuzzers with fuzzer mode disabled. Fuzzer mode explores the handshake, but at the cost of losing coverage on the record layer. Add a separate build flag and client/server corpora for this mode. Note this requires tweaks in consumers' fuzzer build definitions. BUG=111 Change-Id: I1026dc7301645e165a761068a1daad6eedc9271e Reviewed-on: https://boringssl-review.googlesource.com/12108 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-11-04 22:59:33 +00:00
add_definitions(-DBORINGSSL_UNSAFE_DETERMINISTIC_MODE)
set(RUNNER_ARGS "-deterministic")
if(NOT NO_FUZZER_MODE)
add_definitions(-DBORINGSSL_UNSAFE_FUZZER_MODE)
set(RUNNER_ARGS ${RUNNER_ARGS} "-fuzzer" "-shim-config" "fuzzer_mode.json")
endif()
Add a deterministic PRNG for fuzzing. If running the stack through a fuzzer, we would like execution to be completely deterministic. This is gated on a BORINGSSL_UNSAFE_FUZZER_MODE #ifdef. For now, this just uses the zero ChaCha20 key and a global counter. As needed, we can extend this to a thread-local counter and a separate ChaCha20 stream and counter per input length. Change-Id: Ic6c9d8a25e70d68e5dc6804e2c234faf48e51395 Reviewed-on: https://boringssl-review.googlesource.com/7286 Reviewed-by: Adam Langley <agl@google.com>
2016-03-02 03:57:32 +00:00
Switch to Clang 6.0's fuzzer support. With Clang 6.0, libFuzzer is now included and there's a new -fsanitize=fuzzer command to enable the needed compiler actions. Change-Id: If8c0d649f494655c5bb1e55ebdbf39450940c75b Reviewed-on: https://boringssl-review.googlesource.com/31324 Reviewed-by: David Benjamin <davidben@google.com>
2018-08-24 18:46:01 +01:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address,fuzzer-no-link -fsanitize-coverage=edge,indirect-calls")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address,fuzzer-no-link -fsanitize-coverage=edge,indirect-calls")
Add four, basic fuzz tests. This change adds fuzzing tests for: ∙ Certificate parsing ∙ Private key parsing ∙ ClientHello parsing ∙ Server first flow (ServerHello, Certificate, etc) parsing. Change-Id: I5f53282263eaaff69b1a03c819cca73750433653 Reviewed-on: https://boringssl-review.googlesource.com/6460 Reviewed-by: Adam Langley <agl@google.com>
2015-11-09 21:57:26 +00:00
endif()
Add visibility rules. This change marks public symbols as dynamically exported. This means that it becomes viable to build a shared library of libcrypto and libssl with -fvisibility=hidden. On Windows, one not only needs to mark functions for export in a component, but also for import when using them from a different component. Because of this we have to build with |BORINGSSL_IMPLEMENTATION| defined when building the code. Other components, when including our headers, won't have that defined and then the |OPENSSL_EXPORT| tag becomes an import tag instead. See the #defines in base.h In the asm code, symbols are now hidden by default and those that need to be exported are wrapped by a C function. In order to support Chromium, a couple of libssl functions were moved to ssl.h from ssl_locl.h: ssl_get_new_session and ssl_update_cache. Change-Id: Ib4b76e2f1983ee066e7806c24721e8626d08a261 Reviewed-on: https://boringssl-review.googlesource.com/1350 Reviewed-by: Adam Langley <agl@google.com>
2014-07-31 00:02:14 +01:00
add_definitions(-DBORINGSSL_IMPLEMENTATION)
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(BUILD_SHARED_LIBS)
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
add_definitions(-DBORINGSSL_SHARED_LIBRARY)
# Enable position-independent code globally. This is needed because
# some library targets are OBJECT libraries.
set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
Honor the standard BUILD_SHARED_LIBS cmake variable. The variable switches the default type for add_library from STATIC to SHARED. We can condition additional stuff on that for convenience. (tabtest still doesn't build.) BoringSSL as any kind of stable system shared library is still very much unsupported, but this is probably handy for making sure we don't forget all those pesky OPENSSL_EXPORTs. Change-Id: I66ab80bcddbf3724e03e85384141fdf4f4acbc2e Reviewed-on: https://boringssl-review.googlesource.com/3092 Reviewed-by: Adam Langley <agl@google.com>
2015-01-28 05:50:21 +00:00
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(MSAN)
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(NOT CLANG)
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
message(FATAL_ERROR "Cannot enable MSAN unless using Clang")
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(ASAN)
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
message(FATAL_ERROR "ASAN and MSAN are mutually exclusive")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer")
Automatically disable assembly with MSAN. MSAN is incompatible with hand-written assembly code. Previously we required that OPENSSL_NO_ASM be set when building with MSAN, and the CMake build would take care of this. However, with other build systems it wasn't always so easy. This change automatically disables assembly when the compiler is configured for MSAN. Change-Id: I6c219120f62d16b99bafc2efb02948ecbecaf87f Reviewed-on: https://boringssl-review.googlesource.com/31724 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-09-07 19:20:23 +01:00
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer")
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(ASAN)
Build with clang-cl standalone. Our build logic needed to revised and and clang implements more warnings than MSVC, so GTest needed more fixes. Bug: 200 Change-Id: I84c5dd0c51079dd9c990e08dbea7f9022a7d6842 Reviewed-on: https://boringssl-review.googlesource.com/21204 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-10-05 20:04:08 +01:00
if(NOT CLANG)
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
message(FATAL_ERROR "Cannot enable ASAN unless using Clang")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address -fsanitize-address-use-after-scope -fno-omit-frame-pointer")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fsanitize-address-use-after-scope -fno-omit-frame-pointer")
endif()
Add a CFI build flag. This uses Clang's CFI feature. Bug: 201 Change-Id: I7a42ec73dc8bfb3893ec69f2d2f4d7e3a2fd2cc4 Reviewed-on: https://boringssl-review.googlesource.com/23225 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Steven Valdez <svaldez@google.com>
2017-11-21 13:16:42 +00:00
if(CFI)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable CFI unless using Clang")
endif()
Remove -fsanitize-cfi-icall-generalize-pointers. Bug: chromium:785442 Change-Id: Ia073fcae716541bc9d008e3e2148e9f0ac30e637 Reviewed-on: https://boringssl-review.googlesource.com/c/32121 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2018-09-22 22:19:15 +01:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=cfi -fno-sanitize-trap=cfi -flto=thin")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=cfi -fno-sanitize-trap=cfi -flto=thin")
Add a CFI build flag. This uses Clang's CFI feature. Bug: 201 Change-Id: I7a42ec73dc8bfb3893ec69f2d2f4d7e3a2fd2cc4 Reviewed-on: https://boringssl-review.googlesource.com/23225 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Steven Valdez <svaldez@google.com>
2017-11-21 13:16:42 +00:00
# We use Chromium's copy of clang, which requires -fuse-ld=lld if building
# with -flto. That, in turn, can't handle -ggdb.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fuse-ld=lld")
string(REPLACE "-ggdb" "-g" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
string(REPLACE "-ggdb" "-g" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
# -flto causes object files to contain LLVM bitcode. Mixing those with
# assembly output in the same static library breaks the linker.
set(OPENSSL_NO_ASM "1")
endif()
Add a basic TSan test for ref-counts. Confirmed that, if the locks are commented out, TSan catches the threading error. Change-Id: I3e4ef9a7ca85fdbacf8c8b13694a5a54c6d5f99b Reviewed-on: https://boringssl-review.googlesource.com/29924 Reviewed-by: Adam Langley <agl@google.com>
2018-07-19 22:50:45 +01:00
if(TSAN)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable TSAN unless using Clang")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=thread")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=thread")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=thread")
endif()
Add an option to build with UBSan. Change-Id: I31d5660fa4792bbb1ef8a721bad4bdbdb0e56863 Reviewed-on: https://boringssl-review.googlesource.com/c/34445 Reviewed-by: Adam Langley <agl@google.com>
2019-01-21 07:25:12 +00:00
if(UBSAN)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable UBSAN unless using Clang")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=undefined")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=undefined")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=undefined")
if(NOT UBSAN_RECOVER)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-sanitize-recover=undefined")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-sanitize-recover=undefined")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fno-sanitize-recover=undefined")
endif()
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(GCOV)
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fprofile-arcs -ftest-coverage")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs -ftest-coverage")
endif()
if(FIPS)
add_definitions(-DBORINGSSL_FIPS)
Switch to new delocate tool. Most importantly, this version of delocate works for ppc64le. It should also work for x86-64, but will need significant testing to make sure that it covers all the cases that the previous delocate.go covered. It's less stringtastic than the old code, however the parser isn't as nice as I would have liked. I thought that the reason we put up with AT&T syntax with Intel is so that assembly syntax could be somewhat consistent across platforms. At least for ppc64le, that does not appear to be the case. Change-Id: Ic7e3c6acc3803d19f2c3ff5620c5e39703d74212 Reviewed-on: https://boringssl-review.googlesource.com/16464 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-05-17 21:05:50 +01:00
if(FIPS_BREAK_TEST)
add_definitions("-DBORINGSSL_FIPS_BREAK_${FIPS_BREAK_TEST}=1")
endif()
# Delocate does not work for ASan and MSan builds.
if(NOT ASAN AND NOT MSAN)
set(FIPS_DELOCATE "1")
endif()
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
endif()
Add -DOPENSSL_SMALL to CMake. Adding preprocessor flags requires a lot of typing in the CMake command-line (-DCMAKE_C_FLAGS=-DOPENSSL_SMALL -DCMAKE_CXX_FLAGS=-DOPENSSL_SMALL). Change-Id: Ieafc4155d656306c1f22746f780faa5c1d3e27be Reviewed-on: https://boringssl-review.googlesource.com/26784 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-03-23 17:49:27 +00:00
if(OPENSSL_SMALL)
add_definitions(-DOPENSSL_SMALL)
endif()
Add start of infrastructure for checking constant-time properties. Valgrind's checking of uninitialised memory behaves very much like a check for constant-time code: branches and memory indexes based on uninitialised memory trigger warnings. Therefore, if we can tell Valgrind that some secret is “uninitialised”, it'll give us a warning if we do something non-constant-time with it. This was the idea behind https://github.com/agl/ctgrind. But tricks like that are no longer needed because Valgrind now comes with support for marking regions of memory as defined or not. Therefore we can use that API to check constant-time code. This CL defines |CONSTTIME_SECRET| and |CONSTTIME_DECLASSIFY|, which are no-ops unless the code is built with |BORINGSSL_CONSTANT_TIME_VALIDATION| defined, which it isn't by default. So this CL is a no-op itself so far. But it does show that a couple of bits of constant-time time are, in fact, constant-time—seemingly even when compiled with optimisations, which is nice. The annotations in the RSA code are a) probably not marking all the secrets as secret, and b) triggers warnings that are a little interesting: The anti-glitch check calls |BN_mod_exp_mont| which checks that the input is less than the modulus. Of course, it is because the input is the RSA plaintext that we just decrypted, but the plaintext is supposed to be secret and so branching based on its contents isn't allows by Valgrind. The answer isn't totally clear, but I've run out of time on this for now. Change-Id: I1608ed0b22d201e97595fafe46127159e02d5b1b Reviewed-on: https://boringssl-review.googlesource.com/c/33504 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2018-12-07 01:15:58 +00:00
if(CONSTANT_TIME_VALIDATION)
add_definitions(-DBORINGSSL_CONSTANT_TIME_VALIDATION)
# Asserts will often test secret data.
add_definitions(-DNDEBUG)
endif()
Use Go modules with delocate. This makes running go test, etc., in util/fipstools/delocate work! This adds a go_executable command to CMake like: go_executable(delocate boringssl.googlesource.com/boringssl/util/fipstools/delocate) which internally gets dependencies and whatnot so it behaves like usual Go. Update-Note: delocate has been rearranged a bit. Change-Id: I244a7317dd8d4f2ab77a0daa624ed3e0b385faef Reviewed-on: https://boringssl-review.googlesource.com/31885 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2018-09-13 22:37:28 +01:00
function(go_executable dest package)
set(godeps "${CMAKE_SOURCE_DIR}/util/godeps.go")
if(${CMAKE_VERSION} VERSION_LESS "3.7" OR
NOT ${CMAKE_GENERATOR} STREQUAL "Ninja")
# The DEPFILE parameter to add_custom_command is new as of CMake 3.7 and
# only works with Ninja. Query the sources at configure time. Additionally,
# everything depends on go.mod. That affects what external packages to use.
execute_process(COMMAND ${GO_EXECUTABLE} run ${godeps} -format cmake
-pkg ${package}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
OUTPUT_VARIABLE sources
RESULT_VARIABLE godeps_result)
add_custom_command(OUTPUT ${dest}
COMMAND ${GO_EXECUTABLE} build
-o ${CMAKE_CURRENT_BINARY_DIR}/${dest} ${package}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
DEPENDS ${sources} ${CMAKE_SOURCE_DIR}/go.mod)
else()
# Ninja expects the target in the depfile to match the output. This is a
# relative path from the build directory.
string(LENGTH "${CMAKE_BINARY_DIR}" root_dir_length)
math(EXPR root_dir_length "${root_dir_length} + 1")
string(SUBSTRING "${CMAKE_CURRENT_BINARY_DIR}" ${root_dir_length} -1 target)
set(target "${target}/${dest}")
set(depfile "${CMAKE_CURRENT_BINARY_DIR}/${dest}.d")
add_custom_command(OUTPUT ${dest}
COMMAND ${GO_EXECUTABLE} build
-o ${CMAKE_CURRENT_BINARY_DIR}/${dest} ${package}
COMMAND ${GO_EXECUTABLE} run ${godeps} -format depfile
-target ${target} -pkg ${package} -out ${depfile}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
DEPENDS ${godeps} ${CMAKE_SOURCE_DIR}/go.mod
DEPFILE ${depfile})
endif()
endfunction()
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
# CMake's iOS support uses Apple's multiple-architecture toolchain. It takes an
# architecture list from CMAKE_OSX_ARCHITECTURES, leaves CMAKE_SYSTEM_PROCESSOR
# alone, and expects all architecture-specific logic to be conditioned within
# the source files rather than the build. This does not work for our assembly
# files, so we fix CMAKE_SYSTEM_PROCESSOR and only support single-architecture
# builds.
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(NOT OPENSSL_NO_ASM AND CMAKE_OSX_ARCHITECTURES)
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
list(LENGTH CMAKE_OSX_ARCHITECTURES NUM_ARCHES)
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(NOT ${NUM_ARCHES} EQUAL 1)
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
message(FATAL_ERROR "Universal binaries not supported.")
endif()
list(GET CMAKE_OSX_ARCHITECTURES 0 CMAKE_SYSTEM_PROCESSOR)
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(OPENSSL_NO_ASM)
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
add_definitions(-DOPENSSL_NO_ASM)
set(ARCH "generic")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(ARCH "x86_64")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "amd64")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(ARCH "x86_64")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "AMD64")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
# cmake reports AMD64 on Windows, but we might be building for 32-bit.
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(CMAKE_CL_64)
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(ARCH "x86_64")
else()
set(ARCH "x86")
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(ARCH "x86")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "i386")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(ARCH "x86")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "i686")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(ARCH "x86")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "aarch64")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
set(ARCH "aarch64")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "arm64")
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
set(ARCH "aarch64")
Support assembly building for arm64e architecture. iPhone XS/XS MAX/XR uses arm64e. Change-Id: I89bd6b9307176c03fdc1a402ce6b8df080b00653 Reviewed-on: https://boringssl-review.googlesource.com/c/33224 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-11-15 01:20:42 +00:00
# Apple A12 Bionic chipset which is added in iPhone XS/XS Max/XR uses arm64e architecture.
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "arm64e")
set(ARCH "aarch64")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^arm*")
Add the start of standalone iOS build support. The built-in CMake support seems to basically work, though it believes you want to build a fat binary which doesn't work with how we build perlasm. (We'd need to stop conditioning on CMAKE_SYSTEM_PROCESSOR at all, wrap all the generated assembly files in ifdefs, and convince the build to emit more than one. Probably not worth bothering for now.) We still, of course, need to actually test the assembly on iOS before this can be shipped anywhere. BUG=48 Change-Id: I6ae71d98d706be03142b82f7844d1c9b02a2b832 Reviewed-on: https://boringssl-review.googlesource.com/14645 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-07 04:26:04 +01:00
set(ARCH "arm")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "mips")
Allow building on MIPS. Change-Id: I596e77fa5a7b97b405f52c44e9e36a8226196997 Reviewed-on: https://boringssl-review.googlesource.com/11900 Reviewed-by: Adam Langley <agl@google.com>
2016-10-28 14:05:32 +01:00
# Just to avoid the “unknown processor” error.
Don't leave ARCH unset for mips. CMake's language is a little dumb about string interpolation. Set it to "generic", which is the value OPENSSL_NO_ASM uses. Change-Id: Id98a0309e24465f10bcd7dab4a2000d1038edac0 Reviewed-on: https://boringssl-review.googlesource.com/13261 Reviewed-by: Kenny Root <kroot@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2017-01-24 22:18:09 +00:00
set(ARCH "generic")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "ppc64le")
Add ppc64le vector implementation of SHA-1. This change contains a C implementation of SHA-1 for POWER using AltiVec. It is almost as fast as the scalar-only assembly implementation for POWER/POWERPC family in OpenSSL but it is easier to maintain and it allows error checking with tools like ASAN. This is tested only for ppc64le. It may nor may not work for other platforms in the POWER/POWERPC familiy. Before: SHA-1 @ 16 bytes: ~30 MB/s SHA-1 @ 8K: ~140 MB/s After: SHA-1 @ 16 bytes: ~70 MB/s SHA-1 @ 8K: ~480 MB/s Change-Id: I790352e86d9c0cc4e1e57d11c5a0aa5b0780ca6b Reviewed-on: https://boringssl-review.googlesource.com/12203 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-11-12 01:18:53 +00:00
set(ARCH "ppc64le")
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
else()
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
message(FATAL_ERROR "Unknown processor:" ${CMAKE_SYSTEM_PROCESSOR})
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(ANDROID AND NOT ANDROID_NDK_REVISION AND ${ARCH} STREQUAL "arm")
Scope CMAKE_ASM_FLAGS workaround to the old NDK toolchain. The one in the NDK works just fine. In particular, this means one can pass -DCMAKE_ASM_FLAGS="-march=armv8-a" and test the ARMv8 assembler warnings. Additionally, make the workaround put the flags in the other order, so -march is user-overridable. Change-Id: I278ddd17ab688f83ee01f2aca4ff32307f5b0a2d Reviewed-on: https://boringssl-review.googlesource.com/24164 Reviewed-by: Adam Langley <agl@google.com>
2017-12-13 23:08:47 +00:00
# The third-party Android-NDK CMake files somehow fail to set the -march flag
# for assembly files. Without this flag, the compiler believes that it's
Add support for building with the Android NDK. Previously I've been using the Linaro toolchains and just building static binaries. However, the Linaro toolchains have a broken pthread_rwlock_wrlock—it does nothing and then unlocking corrupts the lock. Building with the Android NDK avoids this. These build instructions depend on https://github.com/taka-no-me/android-cmake which people will need to clone into util/ if they want to use the Android NDK. Change-Id: Ic64919f9399af2a57e8df4fb4b3400865ddb2427 Reviewed-on: https://boringssl-review.googlesource.com/4600 Reviewed-by: Adam Langley <agl@google.com>
2015-04-29 01:46:58 +01:00
# building for ARMv5.
Scope CMAKE_ASM_FLAGS workaround to the old NDK toolchain. The one in the NDK works just fine. In particular, this means one can pass -DCMAKE_ASM_FLAGS="-march=armv8-a" and test the ARMv8 assembler warnings. Additionally, make the workaround put the flags in the other order, so -march is user-overridable. Change-Id: I278ddd17ab688f83ee01f2aca4ff32307f5b0a2d Reviewed-on: https://boringssl-review.googlesource.com/24164 Reviewed-by: Adam Langley <agl@google.com>
2017-12-13 23:08:47 +00:00
set(CMAKE_ASM_FLAGS "-march=${CMAKE_SYSTEM_PROCESSOR} ${CMAKE_ASM_FLAGS}")
Add support for building with the Android NDK. Previously I've been using the Linaro toolchains and just building static binaries. However, the Linaro toolchains have a broken pthread_rwlock_wrlock—it does nothing and then unlocking corrupts the lock. Building with the Android NDK avoids this. These build instructions depend on https://github.com/taka-no-me/android-cmake which people will need to clone into util/ if they want to use the Android NDK. Change-Id: Ic64919f9399af2a57e8df4fb4b3400865ddb2427 Reviewed-on: https://boringssl-review.googlesource.com/4600 Reviewed-by: Adam Langley <agl@google.com>
2015-04-29 01:46:58 +01:00
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(${ARCH} STREQUAL "x86" AND APPLE AND ${CMAKE_VERSION} VERSION_LESS "3.0")
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f | xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac
2015-01-29 00:37:10 +00:00
# With CMake 2.8.x, ${CMAKE_SYSTEM_PROCESSOR} evalutes to i386 on OS X,
# but clang defaults to 64-bit builds on OS X unless otherwise told.
# Set ARCH to x86_64 so clang and CMake agree. This is fixed in CMake 3.
set(ARCH "x86_64")
Make build work on OS X with older cmake versions. `uname -p` is still i386 on OS X for some reason, which causes cmake 2.8 to set CMAKE_SYSTEM_PROCESSOR to i386, making the build think it's doing a 32-bit build. However, since the system is almost completely 64-bit these days, clang defaults to producing 64-bit object files unless told otherwise. As a result, the produced .o files are all 64-bit except for the .o files from assembly, and then linking fails. Fix this by forcing ARCH to 64-bit on OS X. This matches the default behavior of cmake 3.0, where CMAKE_SYSTEM_PROCESSOR is x86_64. Change-Id: I7a2abc4cef84dfbaf205852a9d7b647e83dd249f Reviewed-on: https://boringssl-review.googlesource.com/2330 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Piotr Sikora <piotr@cloudflare.com>
2014-11-18 20:14:46 +00:00
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(USE_CUSTOM_LIBCXX)
if(NOT CLANG)
Add an option to statically link a custom libc++. MSan and TSan both require instrumenting everything. Add some machinery so we can do this on the bots. Change-Id: I7d2106bc852ee976455d18787d3a20a35373a9e7 Reviewed-on: https://boringssl-review.googlesource.com/30644 Reviewed-by: Adam Langley <agl@google.com>
2018-08-09 21:33:07 +01:00
message(FATAL_ERROR "USE_CUSTOM_LIBCXX only supported with Clang")
endif()
# CMAKE_CXX_FLAGS ends up in the linker flags as well, so use
# add_compile_options. There does not appear to be a way to set
# language-specific compile-only flags.
add_compile_options("-nostdinc++")
set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS} -nostdlib++")
include_directories(
SYSTEM
util/bot/libcxx/include
util/bot/libcxxabi/include
)
# This is patterned after buildtools/third_party/libc++/BUILD.gn and
# buildtools/third_party/libc++abi/BUILD.gn in Chromium.
file(GLOB LIBCXX_SOURCES "util/bot/libcxx/src/*.cpp")
file(GLOB LIBCXXABI_SOURCES "util/bot/libcxxabi/src/*.cpp")
# This file is meant for exception-less builds.
list(REMOVE_ITEM LIBCXXABI_SOURCES "trunk/src/cxa_noexception.cpp")
# libc++ also defines new and delete.
list(REMOVE_ITEM LIBCXXABI_SOURCES "trunk/src/stdlib_new_delete.cpp")
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(TSAN)
Add an option to statically link a custom libc++. MSan and TSan both require instrumenting everything. Add some machinery so we can do this on the bots. Change-Id: I7d2106bc852ee976455d18787d3a20a35373a9e7 Reviewed-on: https://boringssl-review.googlesource.com/30644 Reviewed-by: Adam Langley <agl@google.com>
2018-08-09 21:33:07 +01:00
# ThreadSanitizer tries to intercept these symbols. Skip them to avoid
# symbol conflicts.
list(REMOVE_ITEM LIBCXXABI_SOURCES "trunk/src/cxa_guard.cpp")
endif()
add_library(libcxxabi ${LIBCXXABI_SOURCES})
target_compile_definitions(
libcxxabi PRIVATE
-D_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS
)
set_target_properties(libcxxabi PROPERTIES COMPILE_FLAGS "-Wno-missing-prototypes -Wno-implicit-fallthrough")
add_library(libcxx ${LIBCXX_SOURCES})
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(ASAN OR MSAN OR TSAN)
Add an option to statically link a custom libc++. MSan and TSan both require instrumenting everything. Add some machinery so we can do this on the bots. Change-Id: I7d2106bc852ee976455d18787d3a20a35373a9e7 Reviewed-on: https://boringssl-review.googlesource.com/30644 Reviewed-by: Adam Langley <agl@google.com>
2018-08-09 21:33:07 +01:00
# Sanitizers try to intercept new and delete.
target_compile_definitions(
libcxx PRIVATE
-D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS
)
endif()
target_compile_definitions(
libcxx PRIVATE
-D_LIBCPP_BUILDING_LIBRARY
-DLIBCXX_BUILDING_LIBCXXABI
)
target_link_libraries(libcxx libcxxabi)
endif()
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
# Add minimal googletest targets. The provided one has many side-effects, and
# googletest has a very straightforward build.
Rename all googletest CMake targets CMake targets are visible globally but gtest_main has boringssl-specific behavior that isn't appropriate for general use. This change makes it possible to use boringssl and abseil-cpp in the same project (since abseil-cpp expects gtest_main to exist and be useful for its own tests). Change-Id: Icc81c11b8bb4b1e21cea7c9fa725b6c082bd5369 Reviewed-on: https://boringssl-review.googlesource.com/24604 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-01-04 07:07:58 +00:00
add_library(boringssl_gtest third_party/googletest/src/gtest-all.cc)
target_include_directories(boringssl_gtest PRIVATE third_party/googletest)
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
include_directories(third_party/googletest/include)
Add a run_tests target to run all tests. It's very annoying having to remember the right incant every time I want to switch around between my build, build-release, build-asan, etc., output directories. Unfortunately, this target is pretty unfriendly without CMake 3.2+ (and Ninja 1.5+). This combination gives a USES_TERMINAL flag to add_custom_target which uses Ninja's "console" pool, otherwise the output buffering gets in the way. Ubuntu LTS is still on an older CMake, so do a version check in the meantime. CMake also has its own test mechanism (CTest), but this doesn't use it. It seems to prefer knowing what all the tests are and then tries to do its own output management and parallelizing and such. We already have our own runners. all_tests.go could actually be converted tidily, but generate_build_files.py also needs to read it, and runner.go has very specific needs. Naming the target ninja -C build test would be nice, but CTest squats that name and CMake grumps when you use a reserved name, so I've gone with run_tests. Change-Id: Ibd20ebd50febe1b4e91bb19921f3bbbd9fbcf66c Reviewed-on: https://boringssl-review.googlesource.com/6270 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-15 02:34:40 +01:00
# Declare a dummy target to build all unit tests. Test targets should inject
# themselves as dependencies next to the target definition.
add_custom_target(all_tests)
Convert aes_test to GTest. This introduces machinery to start embedding the test data files into the crypto_test binary. Figuring out every CI's test data story is more trouble than is worth it. The GTest FileTest runner is considerably different from the old one: - It returns void and expects failures to use the GTest EXPECT_* and ASSERT_* macros, rather than ExpectBytesEqual. This is more monkey work to convert, but ultimately less work to add new tests. I think it's also valuable for our FileTest and normal test patterns to align as much as possible. The line number is emitted via SCOPED_TRACE. - I've intentionally omitted the Error attribute handling, since that doesn't work very well with the new callback. This means evp_test.cc will take a little more work to convert, but this is again to keep our two test patterns aligned. - The callback takes a std::function rather than a C-style void pointer. This means we can go nuts with lambdas. It also places the path first so clang-format doesn't go nuts. BUG=129 Change-Id: I0d1920a342b00e64043e3ea05f5f5af57bfe77b3 Reviewed-on: https://boringssl-review.googlesource.com/16507 Reviewed-by: Adam Langley <agl@google.com>
2017-05-19 20:26:18 +01:00
add_custom_command(
OUTPUT crypto_test_data.cc
COMMAND ${GO_EXECUTABLE} run util/embed_test_data.go ${CRYPTO_TEST_DATA} >
${CMAKE_CURRENT_BINARY_DIR}/crypto_test_data.cc
DEPENDS util/embed_test_data.go ${CRYPTO_TEST_DATA}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
add_library(crypto_test_data OBJECT crypto_test_data.cc)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
add_subdirectory(crypto)
add_subdirectory(ssl)
add_subdirectory(ssl/test)
fipstools: Add a sample binary that exercises methods from the FIPS module. Also allow breaking ECDSA/RSA pair-wise consistency tests and ECDSA self-test. Change-Id: I1c7723f6082568ebf93158cfaa184cbdeb7480a0 Reviewed-on: https://boringssl-review.googlesource.com/16305 Reviewed-by: Adam Langley <agl@google.com>
2017-05-12 23:34:45 +01:00
add_subdirectory(fipstools)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
add_subdirectory(tool)
Add decrepit, initially containing CAST and Blowfish. decrepit will contain algorithms that we really wish didn't exist any longer. It won't be built by default in Chromium etc, but the code will exist for crummy code that still needs it. Change-Id: Ic307f5f0a69efe9e0a5fd54052f49d219e90dcdd
2015-02-03 18:45:12 +00:00
add_subdirectory(decrepit)
Add a run_tests target to run all tests. It's very annoying having to remember the right incant every time I want to switch around between my build, build-release, build-asan, etc., output directories. Unfortunately, this target is pretty unfriendly without CMake 3.2+ (and Ninja 1.5+). This combination gives a USES_TERMINAL flag to add_custom_target which uses Ninja's "console" pool, otherwise the output buffering gets in the way. Ubuntu LTS is still on an older CMake, so do a version check in the meantime. CMake also has its own test mechanism (CTest), but this doesn't use it. It seems to prefer knowing what all the tests are and then tries to do its own output management and parallelizing and such. We already have our own runners. all_tests.go could actually be converted tidily, but generate_build_files.py also needs to read it, and runner.go has very specific needs. Naming the target ninja -C build test would be nice, but CTest squats that name and CMake grumps when you use a reserved name, so I've gone with run_tests. Change-Id: Ibd20ebd50febe1b4e91bb19921f3bbbd9fbcf66c Reviewed-on: https://boringssl-review.googlesource.com/6270 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-15 02:34:40 +01:00
Add four, basic fuzz tests. This change adds fuzzing tests for: ∙ Certificate parsing ∙ Private key parsing ∙ ClientHello parsing ∙ Server first flow (ServerHello, Certificate, etc) parsing. Change-Id: I5f53282263eaaff69b1a03c819cca73750433653 Reviewed-on: https://boringssl-review.googlesource.com/6460 Reviewed-by: Adam Langley <agl@google.com>
2015-11-09 21:57:26 +00:00
if(FUZZ)
Update tools. Unfortunately, this requires partially reverting https://boringssl-review.googlesource.com/31324. This is a mess. While clang proper includes a fuzzer driver, Chromium doesn't use it. Chromium builds exclusively with fuzzer-no-link and links to its own copy of the fuzzer runtime[1]. As of [2], Chromium's clang (which we use on bots) no longer includes the driver, so we must mimic them. However, Chromium's setup is somewhat questionable because fuzzer-no-link pulls in libclang_rt.fuzzer_no_main which still includes most of libclang_rt.fuzzer, just not the one main function[3]. It appears Chromium is actually linking two copies of libclang_rt.fuzzer_no_main. Hopefully this mostly works out as Chromium's clang and libFuzzer should be relatively aligned, but it's not a good assumption for our build, which can take other Clangs too. Thus, if you pass -DFUZZ=1 as-is, we will assume you are using a "normal" Clang with all its relevant runtimes intact. If, however, you are using Chromium clang, you must drop the matching libFuzzer where the bots expected it and build with -DLIBFUZZER_FROM_DEPS=1. This involves no changes to the bots because we never actually unwound all the LIBFUZZER_FROM_DEPS bits before. [1] https://cs.chromium.org/chromium/src/testing/libfuzzer/BUILD.gn?rcl=d21c49585f262e851e2984f96f52905782706325&l=14 [2] https://chromium.googlesource.com/chromium/src/+/c79bf2ea4cf65431dccb57cb2a44528c284645a1 [3] https://github.com/llvm-mirror/compiler-rt/blob/8ebc3668b07fc5cca6010265cd4795443f1c1bea/lib/fuzzer/CMakeLists.txt#L93-L107 https://github.com/llvm-mirror/compiler-rt/blob/8ebc3668b07fc5cca6010265cd4795443f1c1bea/lib/fuzzer/FuzzerMain.cpp Change-Id: I946b3c821c3d7e6def7e07f1381f58241611ba3d Reviewed-on: https://boringssl-review.googlesource.com/c/34184 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-01-07 21:13:04 +00:00
if(LIBFUZZER_FROM_DEPS)
file(GLOB LIBFUZZER_SOURCES "util/bot/libFuzzer/*.cpp")
add_library(Fuzzer STATIC ${LIBFUZZER_SOURCES})
# libFuzzer does not pass our aggressive warnings. It also must be built
# without -fsanitize-coverage options or clang crashes.
set_target_properties(Fuzzer PROPERTIES COMPILE_FLAGS "-Wno-shadow -Wno-format-nonliteral -Wno-missing-prototypes -fsanitize-coverage=0")
endif()
Add four, basic fuzz tests. This change adds fuzzing tests for: ∙ Certificate parsing ∙ Private key parsing ∙ ClientHello parsing ∙ Server first flow (ServerHello, Certificate, etc) parsing. Change-Id: I5f53282263eaaff69b1a03c819cca73750433653 Reviewed-on: https://boringssl-review.googlesource.com/6460 Reviewed-by: Adam Langley <agl@google.com>
2015-11-09 21:57:26 +00:00
add_subdirectory(fuzz)
endif()
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(NOT ${CMAKE_VERSION} VERSION_LESS "3.2")
Add a run_tests target to run all tests. It's very annoying having to remember the right incant every time I want to switch around between my build, build-release, build-asan, etc., output directories. Unfortunately, this target is pretty unfriendly without CMake 3.2+ (and Ninja 1.5+). This combination gives a USES_TERMINAL flag to add_custom_target which uses Ninja's "console" pool, otherwise the output buffering gets in the way. Ubuntu LTS is still on an older CMake, so do a version check in the meantime. CMake also has its own test mechanism (CTest), but this doesn't use it. It seems to prefer knowing what all the tests are and then tries to do its own output management and parallelizing and such. We already have our own runners. all_tests.go could actually be converted tidily, but generate_build_files.py also needs to read it, and runner.go has very specific needs. Naming the target ninja -C build test would be nice, but CTest squats that name and CMake grumps when you use a reserved name, so I've gone with run_tests. Change-Id: Ibd20ebd50febe1b4e91bb19921f3bbbd9fbcf66c Reviewed-on: https://boringssl-review.googlesource.com/6270 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-15 02:34:40 +01:00
# USES_TERMINAL is only available in CMake 3.2 or later.
set(MAYBE_USES_TERMINAL USES_TERMINAL)
endif()
Add -handshaker-path to run_test. Otherwise ninja run_tests doesn't work right build directories named something other than "build" on Linux. Change-Id: I4d7ff319aed338870f5ac071e875fda549bbbd06 Reviewed-on: https://boringssl-review.googlesource.com/30824 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Steven Valdez <svaldez@google.com>
2018-08-10 15:05:20 +01:00
if(UNIX AND NOT APPLE AND NOT ANDROID)
set(HANDSHAKER_ARGS "-handshaker-path" $<TARGET_FILE:handshaker>)
endif()
Add a run_tests target to run all tests. It's very annoying having to remember the right incant every time I want to switch around between my build, build-release, build-asan, etc., output directories. Unfortunately, this target is pretty unfriendly without CMake 3.2+ (and Ninja 1.5+). This combination gives a USES_TERMINAL flag to add_custom_target which uses Ninja's "console" pool, otherwise the output buffering gets in the way. Ubuntu LTS is still on an older CMake, so do a version check in the meantime. CMake also has its own test mechanism (CTest), but this doesn't use it. It seems to prefer knowing what all the tests are and then tries to do its own output management and parallelizing and such. We already have our own runners. all_tests.go could actually be converted tidily, but generate_build_files.py also needs to read it, and runner.go has very specific needs. Naming the target ninja -C build test would be nice, but CTest squats that name and CMake grumps when you use a reserved name, so I've gone with run_tests. Change-Id: Ibd20ebd50febe1b4e91bb19921f3bbbd9fbcf66c Reviewed-on: https://boringssl-review.googlesource.com/6270 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-15 02:34:40 +01:00
add_custom_target(
run_tests
COMMAND ${GO_EXECUTABLE} run util/all_tests.go -build-dir
${CMAKE_BINARY_DIR}
Fix run_tests target. The COMMANDs will “not necessarily composed into a stateful shell or batch script” so the change directory needs to be linked with the command that needs it. This fixes “make run_tests”. Change-Id: I364530fe1331aba7fa9899616916f610981c2c95 Reviewed-on: https://boringssl-review.googlesource.com/11263 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-09-24 00:43:17 +01:00
COMMAND cd ssl/test/runner &&
${GO_EXECUTABLE} test -shim-path $<TARGET_FILE:bssl_shim>
Add -handshaker-path to run_test. Otherwise ninja run_tests doesn't work right build directories named something other than "build" on Linux. Change-Id: I4d7ff319aed338870f5ac071e875fda549bbbd06 Reviewed-on: https://boringssl-review.googlesource.com/30824 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Steven Valdez <svaldez@google.com>
2018-08-10 15:05:20 +01:00
${HANDSHAKER_ARGS} ${RUNNER_ARGS}
Add a run_tests target to run all tests. It's very annoying having to remember the right incant every time I want to switch around between my build, build-release, build-asan, etc., output directories. Unfortunately, this target is pretty unfriendly without CMake 3.2+ (and Ninja 1.5+). This combination gives a USES_TERMINAL flag to add_custom_target which uses Ninja's "console" pool, otherwise the output buffering gets in the way. Ubuntu LTS is still on an older CMake, so do a version check in the meantime. CMake also has its own test mechanism (CTest), but this doesn't use it. It seems to prefer knowing what all the tests are and then tries to do its own output management and parallelizing and such. We already have our own runners. all_tests.go could actually be converted tidily, but generate_build_files.py also needs to read it, and runner.go has very specific needs. Naming the target ninja -C build test would be nice, but CTest squats that name and CMake grumps when you use a reserved name, so I've gone with run_tests. Change-Id: Ibd20ebd50febe1b4e91bb19921f3bbbd9fbcf66c Reviewed-on: https://boringssl-review.googlesource.com/6270 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-15 02:34:40 +01:00
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
Add handshaker as run_tests dependency. Change-Id: I545a61794d6dbb187d973351da6d54e33a608d0d Reviewed-on: https://boringssl-review.googlesource.com/30244 Reviewed-by: Matt Braithwaite <mab@google.com>
2018-08-01 21:54:48 +01:00
DEPENDS all_tests bssl_shim handshaker
Add a run_tests target to run all tests. It's very annoying having to remember the right incant every time I want to switch around between my build, build-release, build-asan, etc., output directories. Unfortunately, this target is pretty unfriendly without CMake 3.2+ (and Ninja 1.5+). This combination gives a USES_TERMINAL flag to add_custom_target which uses Ninja's "console" pool, otherwise the output buffering gets in the way. Ubuntu LTS is still on an older CMake, so do a version check in the meantime. CMake also has its own test mechanism (CTest), but this doesn't use it. It seems to prefer knowing what all the tests are and then tries to do its own output management and parallelizing and such. We already have our own runners. all_tests.go could actually be converted tidily, but generate_build_files.py also needs to read it, and runner.go has very specific needs. Naming the target ninja -C build test would be nice, but CTest squats that name and CMake grumps when you use a reserved name, so I've gone with run_tests. Change-Id: Ibd20ebd50febe1b4e91bb19921f3bbbd9fbcf66c Reviewed-on: https://boringssl-review.googlesource.com/6270 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-15 02:34:40 +01:00
${MAYBE_USES_TERMINAL})
Reference in New Issue Copy Permalink