Use traits structs for StackAllocated and StackAllocatedMovable
This CL refactors StackAllocated{,Movable} to take the init/cleanup/move
function pointers wrapped in a Traits struct (as a typename template
argument) rather than directly as non-type template arguments, to work
around a build issue(*), and it makes the code perhaps marginally
cleaner.
(*) When function pointers are passed directly as non-type template
arguments to StackAllocated / StackAllocatedMovable, clang under
-gsimple-template-names generates DW_TAG_template_value_parameter
relocations in .debug_info pointing directly to those functions. If the
type instantiated by the template has internal init/cleanup functions,
and is used across a shared library boundary, this can cause undefined
symbol linker failures because those functions are not exported, even if
the type is never constructed or destroyed. This occurs in some
configurations for Chromium's component build.
Bug: 549361069
Cq-Include-Trybots: luci.boringssl.try:linux_clang_shared_compile,linux_clang_shared_rel_compile
Change-Id: I0cf796458f50509e99158d2625a7d3e26a6a6964
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/101527
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Lily Chen <chlily@google.com>
Presubmit-BoringSSL-Verified: boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: