In this patch we would vendor google/benchmark and break down the
benchmark into individual translation units, so that the benchmark
framework can apply filters on which benchmark code to run.
This patch vendors google/benchmark 1.9.4
Source: https://github.com/google/benchmark
Commit: eddb0241389718a23a42db6af5f0164b6e0139af
How to run the benchmark:
Benchmarks need to be built by passing in `-DBUILD_TESTING=ON` to CMake,
which is set by default.
To invoke the benchmarks, execute the `bssl_bench` binary.
You have the option to enumerate all of the benchmarks first by passing in
`--benchmark_list_tests`.
To run specific benchmarks, you may pass in `--benchmark_filter=$regex` where
`$regex` is an [`ECMAScript regular expression`](https://cppreference.com/w/cpp/regex/ecmascript.html).
You can specify a set of input sizes in bytes for relevant cipher suites
with the repeatable flag `-i` or `--input-size`.
You can let the benchmark run with a set of various thread counts with the
repeatable flag `-t` or `--threads`.
For more benchmark configuration options, you may read the manual by passing
in `--help` flag on launch.
Co-authored-by: Rudolf Polzer <rpolzer@google.com>
Bug: 383769319
Change-Id: Ic8d4cfd65065e61ae90c58bddb34463a5f398f14
Signed-off-by: Xiangfei Ding <xfding@google.com>
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/83327
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I've kept the LLVM things back for now because Chrome seems to be in
some weird halfway point where libc++abi depends on a macro that libc++
doesn't have yet? I'm not really sure what's going on there and why it's
building for Chrome, but hopefully next time it will have settled.
I've also, for now, kept bazel at 7.5.0. We probably shouldn't update to
8.x on CI until that's our minimum version. There is a 7.6.1, but CIPD's
Bazel packages seem to only make a build for a version if newer than the
latest one, so all 7.x versions after 8.0.0's release are missing.
We may need to do something about this later, but ignoring the problem
for now.
Change-Id: Id17a3b394f68659e91a6dc563aaa40cd6912c1db
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79327
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Notably Go and rules_cc, but also pick up the rest while I'm here.
Updating libc++ once again required reworking the config. They seem to
change it every couple of weeks.
Bug: 396087264
Change-Id: Ied0f6fa11cd8c34fe9f0f87e63fd6283a699a22c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76167
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Apparently Bazel has deprecated the built-in licenses() command and now
expects you to pull in an external package. I think I've gotten this
right?
Since our new BUILD.bazel file is actually referenced by the old
-with-bazel branch, this new dependency also needs to work there. That
is still using the legacy WORKSPACE system, but I got that working there
too, I think. However, as the legacy WORKSPACE system does not consider
recursive dependencies, anyone using it and updating BoringSSL will need
to, in turn, update their WORKSPACE file on update.
Fixed: 365824757
Change-Id: I7b49f33d628cec2ec07a47f0e31f16765d0f532a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71147
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Ben Lawson <benlawson@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Adding a C++ file into libcrypto triggered some more Bazel workarounds
in our build. For whatever reason, that's now being passed a "frozen"
list, so we cannot mutate the values.
This isn't sufficient to fix it, as we're also running into issues with
aes/aes.c being an internal "header". To fix that, I think we have to
bite the bullet and finally rename the FIPS fragments to .h, reflecting
the fact that they are intended to be #included.
Also the new Bazel seems to have a different MODULE.bazel.lock format,
so pick up that update.
Bug: 362664827
Change-Id: Ibf80fa389e0e1fd2b6f1ab110f0dea78a2a1a89b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70627
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In principle, googletest is only needed for tests and could be a
dev_dependency. But it would then be impossible for downstream modules
to run BoringSSL's tests. The downstream module provides the toolchain,
so we may need to request they run tests when triaging issues. If
https://github.com/bazelbuild/bazel/issues/22187 is ever fixed, we can
change this.
With this change, the following works:
cd util/bazel-example
bazelisk test @boringssl//:crypto_test
Change-Id: Ied2276047de134883d6b61b0789f3c7bfcaad669
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68127
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Now that we can generate build files, we can actually maintain a Bazel
build in HEAD, without synthesizing a separate "-with-bazel" branch.
(Though we'll still need both for a transition, and until all the other
build modes have migrated.) Note this has a slightly different directory
structure than the old -with-bazel branch. But the targets are the same
and #include <openssl/whatever.h> still works, so hopefully it's
compatible.
For now, I'm only setting this up with the new bzlmod scheme. Also since
pulling in googletest is much less tedious with bzlmod, I've wired up
tests and everything.
https://bazel.build/external/overview#bzlmod
To build, run commands like:
bazelisk build ...
bazelisk test ...
bazelisk run :bssl
The thinking is we can also go add this to CI and whatnot.
This is also intended to replace the boringssl module in the
bazel-central-registry which someone else set up already. To ease the
transition, I've seeded the compatibility_level value with theirs. (I
think we want to never bump it. Although we don't do SemVer, I think
bzlmod's MVS version selection scheme is generally reasonable. Bumping
it just introduces hiccups into the update process where projects need
to coordinate updates, and we do not want that.)
I wasn't clear on what to put in the version field in the tree, so I
just went with 0.0.0-dev so we don't have to change it, but it's still
vaguely analogous to the versions already in there.
As part of this, I've added support for Bazel's runfiles mechanism in
crypto/test/test_data.cc. This is completely undocumented and I had to
figure out how it works by guessing, but I believe this is the
officially supported way to make cc_test(data = ...) work? The official
documentation says to use devtools_build::GetDataDependencyFilepath, but
that API does not exist in the first place. I've also made it build with
C++17 for now, so we can build libpki, but C++14 consumers should still
be able to use this module, just not build libpki.
To that end, one difference between this and the old module is that we
no longer specify the C++ version in the build. From what I can tell,
Bazel does *not* want libraries to set the C/C++ version and prefers it
only come from the root. Unfortunately, they provide zero tools to
effectively manage this. I've followed this pattern for C++ versions, as
we can assume that Bazel projects are very aware of their C++ version,
but I've explicitly ignored it for the C version. Projects tend not to
change ABIs by C version, so it should be fine to set it internally.
For context when reviewing, the unreadable MODULE.bazel.lock is
automatically generated. I think the idea is that subsequent diffs will
be more readable??
Bug: 542
Change-Id: I88f68b2602a75f58cc6d18832a956f01dc054f58
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67301
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
David Benjamin