commit b18cb6a5d013666b6ac0f29eb8772d33efdf7749
author Adam Langley <agl@google.com> Tue Apr 04 11:08:28 2017 -0700
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Tue Apr 04 18:19:19 2017 +0000
tree daa49fd6f6749056467b1356ab5217cf5e72aeac
parent 42329a828b25259fc47691f5b4a39caf2b29f058

Make the POWER hardware capability value a global in crypto.c.

(Thanks to Sam Panzer for the patch.)

At least some linkers will drop constructor functions if no symbols from
that translation unit are used elsewhere in the program. On POWER, since
the cached capability value isn't a global in crypto.o (like other
platforms), the constructor function is getting discarded.

The C++11 spec says (3.6.2, paragraph 4):

    It is implementation-defined whether the dynamic initialization of a
    non-local variable with static storage duration is done before the
    first statement of main. If the initialization is deferred to some
    point in time after the first statement of main, it shall occur
    before the first odr-use (3.2) of any function or variable defined
    in the same translation unit as the variable to be initialized.

Compilers appear to interpret that to mean they are allowed to drop
(i.e. indefinitely defer) constructors that occur in translation units
that are never used, so they can avoid initializing some part of a
library if it's dropped on the floor.

This change makes the hardware capability value for POWER a global in
crypto.c, which should prevent the constructor function from being
ignored.

Change-Id: I43ebe492d0ac1491f6f6c2097971a277f923dd3e
Reviewed-on: https://boringssl-review.googlesource.com/14664
Commit-Queue: Adam Langley <agl@google.com>
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>

crypto/cpu-ppc64le.c

diff --git a/crypto/cpu-ppc64le.c b/crypto/cpu-ppc64le.c
index c431c81..54571bd 100644
--- a/crypto/cpu-ppc64le.c
+++ b/crypto/cpu-ppc64le.c
@@ -27,14 +27,12 @@
 #define PPC_FEATURE2_HAS_VCRYPTO 0x02000000
 #endif
 
-static unsigned long g_ppc64le_hwcap2 = 0;
-
 void OPENSSL_cpuid_setup(void) {
-  g_ppc64le_hwcap2 = getauxval(AT_HWCAP2);
+  OPENSSL_ppc64le_hwcap2 = getauxval(AT_HWCAP2);
 }
 
 int CRYPTO_is_PPC64LE_vcrypto_capable(void) {
-  return (g_ppc64le_hwcap2 & PPC_FEATURE2_HAS_VCRYPTO) != 0;
+  return (OPENSSL_ppc64le_hwcap2 & PPC_FEATURE2_HAS_VCRYPTO) != 0;
 }
 
 #endif  /* OPENSSL_PPC64LE */

crypto/crypto.c

diff --git a/crypto/crypto.c b/crypto/crypto.c
index c32f514..174c74a 100644
--- a/crypto/crypto.c
+++ b/crypto/crypto.c
@@ -49,6 +49,7 @@
  * far, the init constructor function only sets the capability variables. */
 
 #if defined(OPENSSL_X86) || defined(OPENSSL_X86_64)
+
 /* This value must be explicitly initialised to zero in order to work around a
  * bug in libtool or the linker on OS X.
  *
@@ -57,6 +58,11 @@
  * initialising it to zero, it becomes a "data symbol", which isn't so
  * affected. */
 uint32_t OPENSSL_ia32cap_P[4] = {0};
+
+#elif defined(OPENSSL_PPC64LE)
+
+unsigned long OPENSSL_ppc64le_hwcap2 = 0;
+
 #elif defined(OPENSSL_ARM) || defined(OPENSSL_AARCH64)
 
 #include <openssl/arm_arch.h>

include/openssl/cpu.h

diff --git a/include/openssl/cpu.h b/include/openssl/cpu.h
index 457a476..1a4294a 100644
--- a/include/openssl/cpu.h
+++ b/include/openssl/cpu.h
@@ -171,6 +171,8 @@
  * the Vector.AES category of instructions. */
 int CRYPTO_is_PPC64LE_vcrypto_capable(void);
 
+extern unsigned long OPENSSL_ppc64le_hwcap2;
+
 #endif  /* OPENSSL_PPC64LE */