aboutsummaryrefslogtreecommitdiff
path: root/BUILDING.md
AgeCommit message (Collapse)AuthorFilesLines
2024-03-29Make Go an optional build dependency for the CMake buildDavid Benjamin1-9/+12
Matching the various pre-generated builds, the CMake build no longer actually requires Go. The only things that need it are: - Running tests - Builds with -DFIPS=1 - Builds with the experimental symbol prefixing thing Bug: 542 Change-Id: I52bb427f54dd6e5719cfe77773e87fc394410380 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67367 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-03-22Check in pre-generated perlasm and error data filesDavid Benjamin1-9/+14
This adds a tool for managing pre-generated files, aligning our CMake and non-CMake builds. The plan is roughly: The source of truth for the file lists will (eventually) be build.json. This describes the build in terms of the files that we directly edit. However, we have a two-phase build. First a pregeneration step transforms some of the less convenient inputs into checked in files. Notably perlasm files get expanded. This produces an equivalent JSON structure with fewer inputs. The same tool then outputs that structure into whatever build systems we want. This initial version pre-generates err_data.c and perlasm files. I've not wired up the various build formats, except for CMake (for the CMake build to consume) and JSON (for generate_build_files.py to parse). build.json is also, for now, only a subset of the build. Later changes The upshot of all this is we no longer have a Perl build dependency! Perl is now only needed when working on BoringSSL. It nearly removes the Go one, but Go is still needed to run and (for now) build the tests. To keep the generated files up-to-date, once this lands, I'll update our CI to run `go run ./util/pregenerate -check` which asserts that all generated files are correct. From there we can land the later changes in this patch series that uses this more extensively. My eventual goal is to replace generate_build_files.py altogether and the "master-with-bazel" branch. Instead we'll just have sources.bzl, sources.gni, etc. all checked into the tree directly. And then the normal branch will just have both a CMake and Bazel build in it. Update-Note: generate_build_files.py no longer generates assembly files or err_data.c. Those are now checked into the tree directly. Bug: 542 Change-Id: I71f5ff7417be811f8b7888b345279474e6b38ee9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67288 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-01-16Make the debug vs release build note in BUILDING.md more prominentDavid Benjamin1-6/+9
Change-Id: I3549fb623db267df5956c9412d758749abd2a4dc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65468 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-11-30Use relative links in markdown filesDavid Benjamin1-1/+1
Our repository is sometimes copied into other repositories, at which point all the absolute links don't work. README.md used "./whatever", which seems to work most consistently, so copy that. Change-Id: I63bbf01b8f3870112d1df571adaa6cc82f58e5eb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64347 Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Hubert Chao <hchao@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-11-29add checkout command to BUILDING.mdHubert Chao1-0/+4
Change-Id: If817b912dd016672b7920e1c2e68244d418099d9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64288 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-09-18Bump the minimum CMake version to 3.12David Benjamin1-1/+1
CMake 3.12 was released July 2018, so it meets our five year rule. [0] also requires a CMake version newer than 3.12. [0] https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md Change-Id: I2b21d68e3a379108edde9c7d13450bba52f41235 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63105 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-09-12Require C11 in MSVC tooDavid Benjamin1-5/+5
BoringSSL can currently be built in C11 or pre-C11 mode in MSVC. They're broadly the same, but do use completely different implementations of alignas and alignof. Now that every build configuration I'm aware of has been moved to the C11 mode, we don't even test the pre-C11 mode anymore. Start requiring it. Update-Note: If building with MSVC, BoringSSL now requires building with /std:c11 or later. (On non-MSVC compilers, we have required C11 for a while now.) Fixed: 624 Change-Id: Ie9f66eee0bebac8143c23a7229c6854afaefea6e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63065 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2023-05-08Bump the minimum supported MSVC version to VS2019David Benjamin1-3/+3
This aligns with https://github.com/google/oss-policies-info/pull/8 and https://github.com/grpc/grpc/pull/32614. VS2019 adds a C11 mode, which is useful for us, because it means stdalign.h works correctly. Also bump the minimum Windows SDK to https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/. If you have a new MSVC, CMake will enable C11 mode by default. But if C11 mode is enabled but your Windows SDK is too old, things break. After this change, the CI will include some redundant configurations. All the VS2017 configurations will start testing on VS2019, so the VS2019-specific configurations won't do anything. I'll follow this up with a change to bump those to VS2022, where we're currently missing coverage. Update-Note: BoringSSL now requires VS2019 or later and no longer supports VS2017. VS2017 has been past its "mainstream end date" for over a year now, per https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2017 Change-Id: I3f359e8ea7c9428ddaa9fcc4ffead2ef903398be Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59665 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-04-19Update docs to recommend a much more convenient CMake invocationDavid Benjamin1-14/+9
Newer CMakes support a -B parameter, which saves some fuss. Change-Id: Ifdbbb50b3720cdc42af098eb32941283692e9d99 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58966 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Reviewed-by: Nabil Wadih <nwadih@google.com>
2023-02-22Fix Android tests with new recipe changesDavid Benjamin1-1/+1
After https://chromium-review.googlesource.com/c/chromium/tools/build/+/4277422, the old ANDROID_NATIVE_API_LEVEL values are no longer in CMakeCache.txt. Change-Id: If0c724081ef99bf3bc2e714fe84b6d16925bd116 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57507 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2022-11-22Bump minimum CMake version.David Benjamin1-1/+1
CMake 3.10 was released November 20, 2017, which is now more than five years ago. Change-Id: Ic939fd137983914ce1041740f58d98a56433e739 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55271 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2022-07-12Bump CMake requirement to 3.8.David Benjamin1-1/+1
CMake 3.8 was released April 10, 2017, which puts it past our five year horizon. (CMake 3.9 is just a few days short of it, so using 3.8 for now.) In particular, depending on 3.7+ gets us some nice features like VERSION_GREATER_EQUAL. Change-Id: I90457ad41e7add3c6b2dd3664da964c4b6ede499 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53345 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-04-20Try to require C11 (in non-MSVC compilers).David Benjamin1-1/+2
MSVC is a little behind, but otherwise we should be able to assume C11 support in all our compilers. The only C99 builds should just be stale build files. Such consumers are leaving performance on the table, by using the worse refcounting implementation. For now, don't require it in public headers. Android's build is still defaulting to C99, which means requiring C11 will be disruptive. We can try the public headers after that's fixed. Update-Note: If the build fails with an error about C11, remove -std=c99 or -std=gnu99 from your build. Refcounting will get faster. Change-Id: I2ec6f7d7acc026a451851d0c38f60c14bae6b00f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52247 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-04-20Try to require C++14.David Benjamin1-1/+1
Now that we've dropped MSVC 2015, I believe we can rely on C++14 (which is now seven years old). This switches the build to require C++14. I've gone ahead and switched code in both public headers and within the library, but if the public headers are a problem, we can revert those separately. C++14 doesn't get us quite as much as C++17, but see if we can get to C++14 first. Still, std::enable_if_t and the less restricted constexpr are nice wins. Update-Note: C++14 is now required to build BoringSSL. If the build breaks, make sure your compiler is C++14-capable and is not passing -std=c++11. If this is causing problems for your project, let us know. Change-Id: If03a88e3f8a11980180781f95b806e7f3c3cb6c3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52246 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-03-23Remove VS 2015 support.David Benjamin1-6/+4
VS 2017 was released in March 2017, five years ago now. This means VS 2015 is now past our support window. This will make the unmarked and "vs2017" configs in CI/CQ do the same thing. I'll follow up with a separate CL in infra/config to switch the test VS 2019 instead. Update-Note: BoringSSL may no longer build with VS 2015. Consumers should upgrade to the latest Visual Studio release. VS 2017 or later is required. Change-Id: I477759deb95a27efe132de76d9ed103826110df0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52085 Reviewed-by: Bob Beck <bbe@google.com> Reviewed-by: Adam Langley <agl@google.com>
2022-01-07Switch __ARM_FEATURE_CRYPTO to __ARM_FEATURE_{AES,SHA2}.David Benjamin1-3/+5
The latest version of ACLE splits __ARM_FEATURE_CRYPTO into two defines to reflect that, starting ARMv8.2, the cryptography extension can include {AES,PMULL} and {SHA1,SHA256} separately. Also standardize on __ARM_NEON, which is the recommended symbol from ACLE, and the only one defined on non-Apple aarch64 targets. Digging through GCC history, __ARM_NEON__ is a bit older. __ARM_NEON was added in GCC's 9e94a7fc5ab770928b9e6a2b74e292d35b4c94da from 2012, part of GCC 4.8.0. I suspect we can stop paying attention to __ARM_NEON__ at this point, but I've left both working for now. __ARM_FEATURE_{AES,SHA2} is definite too new to fully replace __ARM_FEATURE_CRYPTO. Tested on Linux that -march=armv8-a+aes now also drops the fallback AES code. Previously, we would pick up -march=armv8-a+crypto, but not -march=armv8-a+aes. Also tested that, on an OPENSSL_STATIC_ARMCAP build, -march=armv8-a+sha2 sets the SHA-1 and SHA-256 features. Change-Id: I749bdbc501ba2da23177ddb823547efcd77e5c98 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50847 Reviewed-by: Adam Langley <agl@google.com>
2022-01-05Enable SHA-512 ARM acceleration when available.David Benjamin1-16/+19
This imports the changes to sha512-armv8.pl from upstream's af0fcf7b4668218b24d9250b95e0b96939ccb4d1. Tweaks needed: - Add an explicit .text because we put .LK$BITS in .rodata for XOM - .LK$bits and code are in separate sections, so use adrp/add instead of plain adr - Where glibc needs feature flags to *enable* pthread_rwlock, Apple interprets _XOPEN_SOURCE as a request to *disable* Apple extensions. Tighten the condition on the _XOPEN_SOURCE check. Added support for macOS and Linux, tested manually on an ARM Mac and a VM, respectively. Fuchsia and Windows do not currently have APIs to expose this bit, so I've left in TODOs. Benchmarks from an Apple M1 Max: Before: Did 4647000 SHA-512 (16 bytes) operations in 1000103us (74.3 MB/sec) Did 1614000 SHA-512 (256 bytes) operations in 1000379us (413.0 MB/sec) Did 439000 SHA-512 (1350 bytes) operations in 1001694us (591.6 MB/sec) Did 76000 SHA-512 (8192 bytes) operations in 1011821us (615.3 MB/sec) Did 39000 SHA-512 (16384 bytes) operations in 1024311us (623.8 MB/sec) After: Did 10369000 SHA-512 (16 bytes) operations in 1000088us (165.9 MB/sec) [+123.1%] Did 3650000 SHA-512 (256 bytes) operations in 1000079us (934.3 MB/sec) [+126.2%] Did 1029000 SHA-512 (1350 bytes) operations in 1000521us (1388.4 MB/sec) [+134.7%] Did 175000 SHA-512 (8192 bytes) operations in 1001874us (1430.9 MB/sec) [+132.5%] Did 89000 SHA-512 (16384 bytes) operations in 1010314us (1443.3 MB/sec) [+131.4%] (This doesn't seem to change the overall SHA-256 vs SHA-512 performance question on ARM, when hashing perf matters. SHA-256 on the same chip gets up to 2454.6 MB/s.) In terms of build coverage, for now, we'll have build coverage everywhere and test coverage on Chromium, which runs this code on macOS CI. We should request a macOS ARM64 bot for our standalone CI. Longer term, we need a QEMU-based builder to test various features. QEMU seems to have pretty good coverage of all this, which will at least give us Linux. I haven't added an OPENSSL_STATIC_ARMCAP_SHA512 for now. Instead, we just look at the standard __ARM_FEATURE_SHA512 define. Strangely, the corresponding -march tag is not sha512. Neither GCC and nor Clang have -march=armv8-a+sha512. Instead, -march=armv8-a+sha3 implies both __ARM_FEATURE_SHA3 and __ARM_FEATURE_SHA512! Yet everything else seems to describe the SHA512 extension as separate from SHA3. https://developer.arm.com/architectures/system-architectures/software-standards/acle Update-Note: Consumers with a different build setup may need to limit -D_XOPEN_SOURCE=700 to Linux or non-Apple platforms. Otherwise, <sys/types.h> won't define some typedef needed by <sys/sysctl.h>. If you see a build error about u_char, etc., being undefined in some system header, that is probably the cause. Change-Id: Ia213d3796b84c71b7966bb68e0aec92e5d7d26f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50807 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-08-17Bump minimum GCC version and note impending VS2015 deprecation.David Benjamin1-2/+4
GCC 6.1 was released more than five years ago, April 27, 2016. We can thus drop some bits in the CMake files. https://gcc.gnu.org/releases.html https://gcc.gnu.org/develop.html#num_scheme Also note in BUILDING.md that VS2015 will no longer be supported next year. Then we can cycle our CQ to testing VS2017 + VS2019. (We're currently not testing VS2019 at all, though so far it hasn't been an issue.) I've been running into some VS2015-only C++ issues around conversions, so once we stop testing it, I expect it'll break. Change-Id: I7a3020df2acd61d57409108aa4d99c840b5ca994 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48925 Reviewed-by: Adam Langley <agl@google.com>
2021-03-23Bump minimum CMake version.David Benjamin1-1/+1
CMake 3.5.0 was released March 8, 2016. Per our five year rule, we can require that now: https://cmake.org/pipermail/cmake/2016-March/062947.html Change-Id: I916fdb66e0356e3a8ffbe1e5fa89f51d99a78546 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46345 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2020-12-11Finish switching to NASM.David Benjamin1-8/+0
As of https://chromium-review.googlesource.com/c/chromium/tools/build/+/2586225, we no longer test on Yasm. Yasm hasn't seen a release for over six years now and is missing support for newer x86 instructions. This removes the remnants of support for Yasm on the CI. It also removes the Yasm support we patched into x86nasm.pl, which removes a now unnecessary divergence from upstream. Update-Note: If a x86 Windows asm build breaks, switch from Yasm to NASM. We're also no longer testing NASM on x86_64 Windows, but there wasn't any patch to revert. Change-Id: I016bad8757fcc13240db9f56dd622be518e649d7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44564 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2019-06-13Set a minimum CMake version of 3.0.David Benjamin1-2/+1
CMake 3.0 was released June 10, 2014, just over five years ago. Set the minimum version to 3.0. This cleans up some Mac workarounds. (CMP0025 was introduced in 3.0, so setting the minimum version to 3.0 also enables it.) CMP0025 is important because Clang and Apple Clang use different version numbers. Prior to CMake 3.0, both read as Clang. Starting CMake 3.0, with CMP0025 enabled, they read as Clang and AppleClang. Without this, we cannot sanely version-check clang. Unfortunately, CMP0025 applies at compiler detection, so if BoringSSL is imported as a CMake subproject, we are dependent on the root project setting CMP0025. But if we successfully set a minumum of 3.0, we can reasonably ask consumers to do the same, which will do so. Next up: In December, we can raise the version to CMake 3.1, which adds support for specifying C and C++ language versions in CMake. (Alternatively, Abseil's minimum version is actually 3.5, so maybe we can update more aggressively here.) Update-Note: CMake 2.8 is no longer supported. Update your CMake to the latest version if it has not been updated in five years. Change-Id: I3378567ad7575fc9fac69e05c403d69ea10332e2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36444 Reviewed-by: Adam Langley <agl@google.com>
2019-02-01Add instructions for debugging on Android with gdb.David Benjamin1-0/+15
Android's official documentation seems to assume you're using the NDK build system or Android Studio. I extracted this from one of their scripts a while back. May as well put it somewhere we can easily find it. Change-Id: I259abc54e6935ab537956a7cbf9f80e924a60b7a Reviewed-on: https://boringssl-review.googlesource.com/c/34724 Reviewed-by: Adam Langley <agl@google.com>
2019-01-03Add a CFI tester to CHECK_ABI.David Benjamin1-0/+4
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>
2019-01-03Remove bundled copy of android-cmake.David Benjamin1-4/+0
I don't believe we use this anymore. People using it should upgrade to a newer NDK (or, worst case, download android-cmake themselves). Change-Id: Ia99d7b19d6f2ec3f4ffe90795813b00480dc2d60 Reviewed-on: https://boringssl-review.googlesource.com/c/34004 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-01-02Clarify build requirements.David Benjamin1-17/+21
The minimum versions are largely bogus, since we do not continuously test them. Instead, we've been using Abseil's five year guidelines to decide when to rely on tooling improvements. Document this. Remove the note on how to build Ninja as that'll just get out of date. For instance, they appear to support Python 3 when building now. Explicitly call out that CMake 3.0 will be required next year (released June 2014). 3.0 is the minimum needed to distinguish Clang from AppleClang, without which version checks on Clang don't work. Also document that we require a C++11 compiler for more than just tests these days. Change-Id: I4e5766934edc1d69f7be01f48e855d400adfb5f2 Reviewed-on: https://boringssl-review.googlesource.com/c/33845 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-11-14Switch docs to recommending NASM.David Benjamin1-1/+1
Chromium has now switched to building our assembly with NASM (https://crbug.com/766721), which is more maintained. Next step is to switch remaining folks (Conscrypt, not sure if there's anyone else) and we'll drop Yasm. Change-Id: If4f45399b48d0d7477afb47647e83e7250bf854f Reviewed-on: https://boringssl-review.googlesource.com/c/33144 Reviewed-by: Adam Langley <agl@google.com>
2018-09-24Add util/read_symbols.goJoshua Liebow-Feeser1-1/+5
- Add util/read_symbols.go to read exported symbols from an AR file for use with the symbol prefixing feature - Move util/fipstools/fipscommon/ar.go -> util/ar/ar.go - util/ar/ar.go: Support BSD-style AR files Change-Id: I171b3b952e69c4b87ac04751b7dba3ea9bc2504e Reviewed-on: https://boringssl-review.googlesource.com/32024 Reviewed-by: David Benjamin <davidben@google.com>
2018-09-17Set up Go modules.David Benjamin1-2/+3
This should make it easier for us to reuse Go code properly. util/fipstools is kind of a mess. runner has been using relative imports, but Go seems to prefer this mechanism these days. Update-Note: The import spelling in ssl/test/runner changes. Also we now require Go 1.11. Or you could clone us into GOPATH, but no one does that. Change-Id: I8bf91e1e0345b3d0b3d17f5c642fe78b415b7dde Reviewed-on: https://boringssl-review.googlesource.com/31884 Reviewed-by: Adam Langley <agl@google.com>
2018-09-06Support symbol prefixesJoshua Liebow-Feeser1-0/+22
- 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-03-23Add -DOPENSSL_SMALL to CMake.David Benjamin1-1/+8
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>
2017-12-14Document the NDK's built-in toolchain file.David Benjamin1-4/+9
The third-party toolchain file doesn't actually work with newer NDKs, and the one shipped with the NDK has fewer bugs. Change-Id: I59e1db393f0d66b186fb71590fab14db7faa0756 Reviewed-on: https://boringssl-review.googlesource.com/24165 Reviewed-by: Adam Langley <agl@google.com>
2017-12-13Remove clang assembler .arch workaround.David Benjamin1-12/+0
This makes it difficult to build against the NDK's toolchain file. The problem is __clang__ just means Clang is the frontend and implies nothing about which assembler. When using as, it is fine. When using clang-as on Linux, one needs a clang-as from this year. The only places where we case about clang's integrated assembler are iOS (where perlasm strips out .arch anyway) and build environments like Chromium which have a regularly-updated clang. Thus we can remove this now. Bug: 39 Update-Note: Holler if this breaks the build. If it doesn't break the build, you can probably remove any BORINGSSL_CLANG_SUPPORTS_DOT_ARCH or explicit -march armv8-a+crypto lines in your BoringSSL build. Change-Id: I21ce54b14c659830520c2f1d51c7bd13e0980c68 Reviewed-on: https://boringssl-review.googlesource.com/24124 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-15Revert ADX due to build issues.David Benjamin1-3/+2
Using ADX instructions requires relatively new assemblers. Conscrypt are currently using Yasm 1.2.0. Revert these for the time being to unbreak their build. Change-Id: Iaba5761ccedcafaffb5ca79a8eaf7fa565583c32 Reviewed-on: https://boringssl-review.googlesource.com/19244 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2017-08-14Enable ADX in x86_64-mont*.pl.David Benjamin1-2/+3
This is a reland of https://boringssl-review.googlesource.com/18965 which was reverted due to Windows toolchain problems that have since been fixed. We have an SDE bot now and can more easily test things. We also enabled ADX in rsaz-avx2.pl which does not work without x86_64-mont*.pl enabled. rsa-avx2.pl's ADX code only turns itself off so that the faster ADX code can be used... but we disable it. Verified, after reverting the fix, the test vectors we imported combined with Intel SDE catches CVE-2016-7055, so we do indeed have test coverage. Also verified on the Windows version of Intel SDE. Thanks to Alexey Ivanov for pointing out the discrepancy. Skylake numbers: Before: Did 7296 RSA 2048 signing operations in 10038191us (726.8 ops/sec) Did 209000 RSA 2048 verify operations in 10030629us (20836.2 ops/sec) Did 1080 RSA 4096 signing operations in 10072221us (107.2 ops/sec) Did 60836 RSA 4096 verify operations in 10053929us (6051.0 ops/sec) ADX consistently off: Did 9360 RSA 2048 signing operations in 10025823us (933.6 ops/sec) Did 220000 RSA 2048 verify operations in 10024339us (21946.6 ops/sec) Did 1048 RSA 4096 signing operations in 10006782us (104.7 ops/sec) Did 61936 RSA 4096 verify operations in 10088011us (6139.6 ops/sec) After (ADX consistently on): Did 10444 RSA 2048 signing operations in 10006781us (1043.7 ops/sec) Did 323000 RSA 2048 verify operations in 10012192us (32260.7 ops/sec) Did 1610 RSA 4096 signing operations in 10044930us (160.3 ops/sec) Did 96000 RSA 4096 verify operations in 10075606us (9528.0 ops/sec) Change-Id: I2502ce80e9cfcdea40907512682e3a6663000faa Reviewed-on: https://boringssl-review.googlesource.com/19105 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2017-06-09Set static armcaps based on __ARM_FEATURE_CRYPTO.David Benjamin1-10/+12
Originally we had some confusion around whether the features could be toggled individually or not. Per the ARM C Language Extensions doc[1], __ARM_FEATURE_CRYPTO implies the "crypto extension" which encompasses all of them. The runtime CPUID equivalent can report the features individually, but it seems no one separates them in practice, for now. (If they ever do, probably there'll be a new set of #defines.) [1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf Change-Id: I12915dfc308f58fb005286db75e50d8328eeb3ea Reviewed-on: https://boringssl-review.googlesource.com/16991 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-07Add the start of standalone iOS build support.David Benjamin1-0/+9
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-01-21Do a cursory conversion of a few tests to GTest.David Benjamin1-1/+1
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-16Enable stitched x86-64 AES-NI AES-GCM implementation.Brian Smith1-1/+1
Measured on a SkyLake processor: Before: Did 11373750 AES-128-GCM (16 bytes) seal operations in 1016000us (11194635.8 ops/sec): 179.1 MB/s Did 2253000 AES-128-GCM (1350 bytes) seal operations in 1016000us (2217519.7 ops/sec): 2993.7 MB/s Did 453750 AES-128-GCM (8192 bytes) seal operations in 1015000us (447044.3 ops/sec): 3662.2 MB/s Did 10753500 AES-256-GCM (16 bytes) seal operations in 1016000us (10584153.5 ops/sec): 169.3 MB/s Did 1898750 AES-256-GCM (1350 bytes) seal operations in 1015000us (1870689.7 ops/sec): 2525.4 MB/s Did 374000 AES-256-GCM (8192 bytes) seal operations in 1016000us (368110.2 ops/sec): 3015.6 MB/s After: Did 11074000 AES-128-GCM (16 bytes) seal operations in 1015000us (10910344.8 ops/sec): 174.6 MB/s Did 3178250 AES-128-GCM (1350 bytes) seal operations in 1016000us (3128198.8 ops/sec): 4223.1 MB/s Did 734500 AES-128-GCM (8192 bytes) seal operations in 1016000us (722933.1 ops/sec): 5922.3 MB/s Did 10394750 AES-256-GCM (16 bytes) seal operations in 1015000us (10241133.0 ops/sec): 163.9 MB/s Did 2502250 AES-256-GCM (1350 bytes) seal operations in 1016000us (2462844.5 ops/sec): 3324.8 MB/s Did 544500 AES-256-GCM (8192 bytes) seal operations in 1015000us (536453.2 ops/sec): 4394.6 MB/s Change-Id: If058935796441ed4e577b9a72d3aa43422edba58 Reviewed-on: https://boringssl-review.googlesource.com/7273 Reviewed-by: Adam Langley <alangley@gmail.com>
2017-01-03update required cmake version to 2.8.10Raullen Chai1-1/+1
Change-Id: Ibba0271efa86e1b1af97f2a08b73677dfd236b7a Reviewed-on: https://boringssl-review.googlesource.com/12986 CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2016-08-26Allow .arch directives with Clang.Adam Langley1-0/+12
Some, very recent, versions of Clang now support `.arch`. Allow them to see these directives with BORINGSSL_CLANG_SUPPORTS_DOT_ARCH. BUG=39 Change-Id: I122ab4b3d5f14502ffe0c6e006950dc64abf0201 Reviewed-on: https://boringssl-review.googlesource.com/10600 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-06-10Document compiler and assembler requirements.David Benjamin1-0/+4
The minimum version is purely based on what we've patched out of the perlasm files. I'm assuming they're accurate. Change-Id: I5ae176cf793512125fa78f203a1314396e8a14d7 Reviewed-on: https://boringssl-review.googlesource.com/8238 Reviewed-by: Adam Langley <agl@google.com>
2016-05-19Update Android build instructions.David Benjamin1-8/+8
We now have a copy of android-cmake. Also remove the mention of running cmake twice. It seems to work fine once? The API level also got specified twice somehow. BUG=26 Change-Id: I1331b079a4d8531cd53f7de3605ac318c14b3e26 Reviewed-on: https://boringssl-review.googlesource.com/7985 Reviewed-by: Adam Langley <agl@google.com>
2016-05-02Bump requirements to MSVC 2015.David Benjamin1-1/+1
Track the Chromium requirements. This makes our bots build with 2015 instead of 2013. BUG=43 Change-Id: Id5329900a5d1d5fae4b5b22299ed47bc1b947dd8 Reviewed-on: https://boringssl-review.googlesource.com/7820 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-02-23Enable upstream's ChaCha20 assembly for x86 and ARM (32- and 64-bit).David Benjamin1-10/+0
This removes chacha_vec_arm.S and chacha_vec.c in favor of unifying on upstream's code. Upstream's is faster and this cuts down on the number of distinct codepaths. Our old scheme also didn't give vectorized code on Windows or aarch64. BoringSSL-specific modifications made to the assembly: - As usual, the shelling out to $CC is replaced with hardcoding $avx. I've tested up to the AVX2 codepath, so enable it all. - I've removed the AMD XOP code as I have not tested it. - As usual, the ARM file need the arm_arch.h include tweaked. Speed numbers follow. We can hope for further wins on these benchmarks after importing the Poly1305 assembly. x86 --- Old: Did 1422000 ChaCha20-Poly1305 (16 bytes) seal operations in 1000433us (1421384.5 ops/sec): 22.7 MB/s Did 123000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1003803us (122534.0 ops/sec): 165.4 MB/s Did 22000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1000282us (21993.8 ops/sec): 180.2 MB/s Did 1428000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000214us (1427694.5 ops/sec): 22.8 MB/s Did 124000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1006332us (123219.8 ops/sec): 166.3 MB/s Did 22000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1020771us (21552.3 ops/sec): 176.6 MB/s New: Did 1520000 ChaCha20-Poly1305 (16 bytes) seal operations in 1000567us (1519138.6 ops/sec): 24.3 MB/s Did 152000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1004216us (151361.9 ops/sec): 204.3 MB/s Did 31000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1009085us (30720.9 ops/sec): 251.7 MB/s Did 1797000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000141us (1796746.7 ops/sec): 28.7 MB/s Did 171000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1003204us (170453.9 ops/sec): 230.1 MB/s Did 31000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1005349us (30835.1 ops/sec): 252.6 MB/s x86_64, no AVX2 --- Old: Did 1782000 ChaCha20-Poly1305 (16 bytes) seal operations in 1000204us (1781636.5 ops/sec): 28.5 MB/s Did 317000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1001579us (316500.2 ops/sec): 427.3 MB/s Did 62000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1012146us (61256.0 ops/sec): 501.8 MB/s Did 1778000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000220us (1777608.9 ops/sec): 28.4 MB/s Did 315000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1002886us (314093.5 ops/sec): 424.0 MB/s Did 71000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1014606us (69977.9 ops/sec): 573.3 MB/s New: Did 1866000 ChaCha20-Poly1305 (16 bytes) seal operations in 1000019us (1865964.5 ops/sec): 29.9 MB/s Did 399000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1001017us (398594.6 ops/sec): 538.1 MB/s Did 84000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1005645us (83528.5 ops/sec): 684.3 MB/s Did 1881000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000325us (1880388.9 ops/sec): 30.1 MB/s Did 404000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1000004us (403998.4 ops/sec): 545.4 MB/s Did 85000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1010048us (84154.4 ops/sec): 689.4 MB/s x86_64, AVX2 --- Old: Did 2375000 ChaCha20-Poly1305 (16 bytes) seal operations in 1000282us (2374330.4 ops/sec): 38.0 MB/s Did 448000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1001865us (447166.0 ops/sec): 603.7 MB/s Did 88000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1005217us (87543.3 ops/sec): 717.2 MB/s Did 2409000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000188us (2408547.2 ops/sec): 38.5 MB/s Did 446000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1001003us (445553.1 ops/sec): 601.5 MB/s Did 90000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1006722us (89399.1 ops/sec): 732.4 MB/s New: Did 2622000 ChaCha20-Poly1305 (16 bytes) seal operations in 1000266us (2621302.7 ops/sec): 41.9 MB/s Did 794000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1000783us (793378.8 ops/sec): 1071.1 MB/s Did 173000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1000176us (172969.6 ops/sec): 1417.0 MB/s Did 2623000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000330us (2622134.7 ops/sec): 42.0 MB/s Did 783000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1000531us (782584.4 ops/sec): 1056.5 MB/s Did 174000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1000840us (173854.0 ops/sec): 1424.2 MB/s arm, Nexus 4 --- Old: Did 388550 ChaCha20-Poly1305 (16 bytes) seal operations in 1000580us (388324.8 ops/sec): 6.2 MB/s Did 90000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1003816us (89657.9 ops/sec): 121.0 MB/s Did 19000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1045750us (18168.8 ops/sec): 148.8 MB/s Did 398500 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000305us (398378.5 ops/sec): 6.4 MB/s Did 90500 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1000305us (90472.4 ops/sec): 122.1 MB/s Did 19000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1043278us (18211.8 ops/sec): 149.2 MB/s New: Did 424788 ChaCha20-Poly1305 (16 bytes) seal operations in 1000641us (424515.9 ops/sec): 6.8 MB/s Did 115000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1001526us (114824.8 ops/sec): 155.0 MB/s Did 27000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1033023us (26136.9 ops/sec): 214.1 MB/s Did 447750 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000549us (447504.3 ops/sec): 7.2 MB/s Did 117500 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1001923us (117274.5 ops/sec): 158.3 MB/s Did 27000 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1025118us (26338.4 ops/sec): 215.8 MB/s aarch64, Nexus 6p (Note we didn't have aarch64 assembly before at all, and still don't have it for Poly1305. Hopefully once that's added this will be faster than the arm numbers...) --- Old: Did 145040 ChaCha20-Poly1305 (16 bytes) seal operations in 1003065us (144596.8 ops/sec): 2.3 MB/s Did 14000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1042605us (13427.9 ops/sec): 18.1 MB/s Did 2618 ChaCha20-Poly1305 (8192 bytes) seal operations in 1093241us (2394.7 ops/sec): 19.6 MB/s Did 148000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000709us (147895.1 ops/sec): 2.4 MB/s Did 14000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1047294us (13367.8 ops/sec): 18.0 MB/s Did 2607 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1090745us (2390.1 ops/sec): 19.6 MB/s New: Did 358000 ChaCha20-Poly1305 (16 bytes) seal operations in 1000769us (357724.9 ops/sec): 5.7 MB/s Did 45000 ChaCha20-Poly1305 (1350 bytes) seal operations in 1021267us (44062.9 ops/sec): 59.5 MB/s Did 8591 ChaCha20-Poly1305 (8192 bytes) seal operations in 1047136us (8204.3 ops/sec): 67.2 MB/s Did 343000 ChaCha20-Poly1305-Old (16 bytes) seal operations in 1000489us (342832.4 ops/sec): 5.5 MB/s Did 44000 ChaCha20-Poly1305-Old (1350 bytes) seal operations in 1008326us (43636.7 ops/sec): 58.9 MB/s Did 8866 ChaCha20-Poly1305-Old (8192 bytes) seal operations in 1083341us (8183.9 ops/sec): 67.0 MB/s Change-Id: I629fe195d072f2c99e8f947578fad6d70823c4c8 Reviewed-on: https://boringssl-review.googlesource.com/7202 Reviewed-by: Adam Langley <agl@google.com>
2016-02-10Updating BUILDING.md for windows.nmittler1-6/+14
Updating the Perl docs to describe behavior of Strawberry Perl and possible interaction with CMake on Windows. Also adding a few other links and instructions for using CMake/Ninja to build release mode with position independent code, since this seems generally useful. Change-Id: I616c0d267da749fe90673bc9e8bde9ec181fec25 Reviewed-on: https://boringssl-review.googlesource.com/7113 Reviewed-by: David Benjamin <davidben@google.com>
2016-02-08Update some URLs in BUILDING.md.David Benjamin1-2/+2
Change-Id: Ic7aa22b10d2d69bdc3a548273640574203e93012 Reviewed-on: https://boringssl-review.googlesource.com/7071 Reviewed-by: Adam Langley <agl@google.com>
2015-10-30Make the instructions for downloading the ARM compiler easier to copy and paste.Adam Langley1-5/+5
Change-Id: If78cba6abc36999488981db2a12b039024c757df Reviewed-on: https://boringssl-review.googlesource.com/6391 Reviewed-by: Brian Smith <brian@briansmith.org> Reviewed-by: David Benjamin <davidben@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2015-10-27Add OPENSSL_SMALL.Adam Langley1-0/+4
Intel's P-256 code has very large tables and things like Chromium just don't need that extra size. However, servers generally do so this change adds an OPENSSL_SMALL define that currently just drops the 64-bit P-224 but will gate Intel's P-256 in the future too. Change-Id: I2e55c6e06327fafabef9b96d875069d95c0eea81 Reviewed-on: https://boringssl-review.googlesource.com/6362 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-26Document how to regenerate crypto/chacha/chacha_vec_arm.S.Brian Smith1-19/+24
Also, organize the links in BUILDING.md sensibly. Change-Id: Ie9c65750849fcdab7a6a6bf11d1c9cdafb53bc00 Reviewed-on: https://boringssl-review.googlesource.com/6140 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-26Add a run_tests target to run all tests.David Benjamin1-0/+3
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>
generated by cgit v1.1 at 2024-06-29 01:50:46 +0000