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>
This is an initial cut at aarch64 support. I have only qemu to test it
however—hopefully hardware will be coming soon.
This also affects 32-bit ARM in that aarch64 chips can run 32-bit code
and we would like to be able to take advantage of the crypto operations
even in 32-bit mode. AES and GHASH should Just Work in this case: the
-armx.pl files can be built for either 32- or 64-bit mode based on the
flavour argument given to the Perl script.
SHA-1 and SHA-256 don't work like this however because they've never
support for multiple implementations, thus BoringSSL built for 32-bit
won't use the SHA instructions on an aarch64 chip.
No dedicated ChaCha20 or Poly1305 support yet.
Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c
Reviewed-on: https://boringssl-review.googlesource.com/2801
Reviewed-by: Adam Langley <agl@google.com>
We aren't targeting pure C89 any longer and it also upsets GCC on
AArch64 because asm() isn't part of C89.
Change-Id: I0ba299160e2f0c40d9a99ea8df13b4bb33c08163
Reviewed-on: https://boringssl-review.googlesource.com/2800
Reviewed-by: Adam Langley <agl@google.com>
Bruce Dawson pointed out that the shadowing of |ret| in |s3_srvr.c|
looked dodgy. It was actually deliberate (we don't want to reset the
default value of the function's |ret| variable with a successful return
from the callback) but it does look dodgy.
This change adds -Wshadow to ban variable shadowing and fixes all
current instances.
Change-Id: I1268f88b9f26245c7d16d6ead5bb9014ea471c01
Reviewed-on: https://boringssl-review.googlesource.com/2520
Reviewed-by: Adam Langley <agl@google.com>
`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>
This lets us run bssl speed at least. bssl client is currently compiled
out until we clean up our socket story on Windows and get it working.
Change-Id: Ib1dc0d0e0a6eed7544207e7bbe138503731fda67
Reviewed-on: https://boringssl-review.googlesource.com/2103
Reviewed-by: Adam Langley <agl@google.com>
OBJECT library types are supported only in CMake 2.8.8 or higher, and
attempting to build BoringSSL on Ubuntu 12.04 results in CMake
displaying unhelpful error messages.
Change-Id: I2bc77a2c95d4f6ee41f8489ff679a2a0ba48c508
Reviewed-on: https://boringssl-review.googlesource.com/1530
Reviewed-by: Adam Langley <agl@google.com>
Building under Ubuntu x86 fails with "Unknown processor:i686".
This adds i686 to CMakeLists.txt, fixing the build.
Change-Id: Ic1c7ce452c019b8a2a875d64a707f640d86c7e31
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>
CMake calls "uname" in order to detect the CPU architecture,
so $(CMAKE_SYSTEM_PROCESSOR) varies from platform to platform.
This changes adds support for "i386" and "amd64" values, which
are used by BSDs for the x86 family of CPUs.
Change-Id: I532ce787a9ac06220c92a6d8c78ad5a55d8c40bf
Signed-off-by: Piotr Sikora <piotr@cloudflare.com>
Reviewed-on: https://boringssl-review.googlesource.com/1360
Reviewed-by: Adam Langley <agl@google.com>
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).
(This change contains substantial changes from the original and
effectively starts a new history.)
