Reduce architecture detection in CMake.
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2023-01-25 10:03:53 -05:00
|
|
|
perlasm(BCM_SOURCES aarch64 aesv8-armv8 aes/asm/aesv8-armx.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 aesv8-gcm-armv8 modes/asm/aesv8-gcm-armv8.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 armv8-mont bn/asm/armv8-mont.pl)
|
2023-02-02 14:50:36 -05:00
|
|
|
perlasm(BCM_SOURCES aarch64 bn-armv8 bn/asm/bn-armv8.pl)
|
Reduce architecture detection in CMake.
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2023-01-25 10:03:53 -05:00
|
|
|
perlasm(BCM_SOURCES aarch64 ghash-neon-armv8 modes/asm/ghash-neon-armv8.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 ghashv8-armv8 modes/asm/ghashv8-armx.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 p256_beeu-armv8-asm ec/asm/p256_beeu-armv8-asm.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 p256-armv8-asm ec/asm/p256-armv8-asm.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 sha1-armv8 sha/asm/sha1-armv8.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 sha256-armv8 sha/asm/sha512-armv8.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 sha512-armv8 sha/asm/sha512-armv8.pl)
|
|
|
|
|
perlasm(BCM_SOURCES aarch64 vpaes-armv8 aes/asm/vpaes-armv8.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm aesv8-armv7 aes/asm/aesv8-armx.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm armv4-mont bn/asm/armv4-mont.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm bsaes-armv7 aes/asm/bsaes-armv7.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm ghash-armv4 modes/asm/ghash-armv4.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm ghashv8-armv7 modes/asm/ghashv8-armx.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm sha1-armv4-large sha/asm/sha1-armv4-large.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm sha256-armv4 sha/asm/sha256-armv4.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm sha512-armv4 sha/asm/sha512-armv4.pl)
|
|
|
|
|
perlasm(BCM_SOURCES arm vpaes-armv7 aes/asm/vpaes-armv7.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 aesni-x86 aes/asm/aesni-x86.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 bn-586 bn/asm/bn-586.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 co-586 bn/asm/co-586.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 ghash-ssse3-x86 modes/asm/ghash-ssse3-x86.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 ghash-x86 modes/asm/ghash-x86.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 md5-586 md5/asm/md5-586.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 sha1-586 sha/asm/sha1-586.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 sha256-586 sha/asm/sha256-586.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 sha512-586 sha/asm/sha512-586.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 vpaes-x86 aes/asm/vpaes-x86.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86 x86-mont bn/asm/x86-mont.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 aesni-gcm-x86_64 modes/asm/aesni-gcm-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 aesni-x86_64 aes/asm/aesni-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 ghash-ssse3-x86_64 modes/asm/ghash-ssse3-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 ghash-x86_64 modes/asm/ghash-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 md5-x86_64 md5/asm/md5-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 p256_beeu-x86_64-asm ec/asm/p256_beeu-x86_64-asm.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 p256-x86_64-asm ec/asm/p256-x86_64-asm.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 rdrand-x86_64 rand/asm/rdrand-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 rsaz-avx2 bn/asm/rsaz-avx2.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 sha1-x86_64 sha/asm/sha1-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 sha256-x86_64 sha/asm/sha512-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 sha512-x86_64 sha/asm/sha512-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 vpaes-x86_64 aes/asm/vpaes-x86_64.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 x86_64-mont bn/asm/x86_64-mont.pl)
|
|
|
|
|
perlasm(BCM_SOURCES x86_64 x86_64-mont5 bn/asm/x86_64-mont5.pl)
|
|
|
|
|
|
|
|
|
|
if(OPENSSL_ASM)
|
|
|
|
|
list(APPEND BCM_SOURCES_ASM_USED ${BCM_SOURCES_ASM})
|
2017-04-04 14:21:43 -07:00
|
|
|
endif()
|
Reduce architecture detection in CMake.
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2023-01-25 10:03:53 -05:00
|
|
|
if(OPENSSL_NASM)
|
|
|
|
|
list(APPEND BCM_SOURCES_ASM_USED ${BCM_SOURCES_NASM})
|
2017-04-13 11:00:24 -07:00
|
|
|
endif()
|
|
|
|
|
|
2017-05-17 13:05:50 -07:00
|
|
|
if(FIPS_DELOCATE)
|
2019-05-09 16:39:49 -07:00
|
|
|
if(FIPS_SHARED)
|
|
|
|
|
error("Can't set both delocate and shared mode for FIPS build")
|
|
|
|
|
endif()
|
|
|
|
|
|
2017-04-04 14:21:43 -07:00
|
|
|
add_library(
|
|
|
|
|
bcm_c_generated_asm
|
|
|
|
|
|
|
|
|
|
STATIC
|
|
|
|
|
|
|
|
|
|
bcm.c
|
|
|
|
|
)
|
Remove global_target from build.
This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-05 13:44:26 -05:00
|
|
|
add_dependencies(bcm_c_generated_asm boringssl_prefix_symbols)
|
2023-02-04 20:06:30 -05:00
|
|
|
target_include_directories(bcm_c_generated_asm PRIVATE ../../include)
|
2017-04-26 15:04:48 -07:00
|
|
|
set_target_properties(bcm_c_generated_asm PROPERTIES COMPILE_OPTIONS "-S")
|
|
|
|
|
set_target_properties(bcm_c_generated_asm PROPERTIES POSITION_INDEPENDENT_CODE ON)
|
|
|
|
|
|
2022-11-23 17:23:15 +00:00
|
|
|
set(TARGET "")
|
|
|
|
|
if(CMAKE_ASM_COMPILER_TARGET)
|
|
|
|
|
set(TARGET "--target=${CMAKE_ASM_COMPILER_TARGET}")
|
|
|
|
|
endif()
|
|
|
|
|
|
2018-09-13 16:37:28 -05:00
|
|
|
go_executable(delocate boringssl.googlesource.com/boringssl/util/fipstools/delocate)
|
2017-04-04 14:21:43 -07:00
|
|
|
add_custom_command(
|
|
|
|
|
OUTPUT bcm-delocated.S
|
2022-11-23 17:23:15 +00:00
|
|
|
COMMAND
|
|
|
|
|
./delocate
|
|
|
|
|
-a $<TARGET_FILE:bcm_c_generated_asm>
|
|
|
|
|
-o bcm-delocated.S
|
|
|
|
|
-cc ${CMAKE_ASM_COMPILER}
|
|
|
|
|
-cc-flags "${TARGET} $CMAKE_ASM_FLAGS"
|
|
|
|
|
${PROJECT_SOURCE_DIR}/include/openssl/arm_arch.h
|
Consistently include BTI markers in every assembly file
Trying to migrate Chromium to the "link all the asm files together"
strategy broke the aarch64 Android build because some of the ifdef'd out
assembly files were missing the .note.gnu.property section for BTI. If
we add support for IBT, that'll be another one.
To fix this, introduce <openssl/asm_base.h>, which must be included at
the start of every assembly file (before the target ifdefs). This does a
couple things:
- It emits BTI and noexecstack markers into every assembly file, even
those that ifdef themselves out.
- It resolves the MSan -> OPENSSL_NO_ASM logic, so we only need to do it
once.
- It defines the same OPENSSL_X86_64, etc., defines we set elsewhere, so
we can ensure they're consistent.
This required carving files up a bit. <openssl/base.h> has a lot of
things, such that trying to guard everything in it on __ASSEMBLER__
would be tedious. Instead, I moved the target defines to a new
<openssl/target.h>. Then <openssl/asm_base.h> is the new header that
pulls in all those things.
Bug: 542
Change-Id: I1682b4d929adea72908655fa1bb15765a6b3473b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60765
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
2023-06-12 18:11:13 -04:00
|
|
|
${PROJECT_SOURCE_DIR}/include/openssl/asm_base.h
|
|
|
|
|
${PROJECT_SOURCE_DIR}/include/openssl/target.h
|
Reduce architecture detection in CMake.
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2023-01-25 10:03:53 -05:00
|
|
|
${BCM_SOURCES_ASM_USED}
|
2022-11-23 17:23:15 +00:00
|
|
|
DEPENDS
|
|
|
|
|
bcm_c_generated_asm
|
|
|
|
|
delocate
|
Reduce architecture detection in CMake.
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2023-01-25 10:03:53 -05:00
|
|
|
${BCM_SOURCES_ASM_USED}
|
2022-11-23 17:23:15 +00:00
|
|
|
${PROJECT_SOURCE_DIR}/include/openssl/arm_arch.h
|
Consistently include BTI markers in every assembly file
Trying to migrate Chromium to the "link all the asm files together"
strategy broke the aarch64 Android build because some of the ifdef'd out
assembly files were missing the .note.gnu.property section for BTI. If
we add support for IBT, that'll be another one.
To fix this, introduce <openssl/asm_base.h>, which must be included at
the start of every assembly file (before the target ifdefs). This does a
couple things:
- It emits BTI and noexecstack markers into every assembly file, even
those that ifdef themselves out.
- It resolves the MSan -> OPENSSL_NO_ASM logic, so we only need to do it
once.
- It defines the same OPENSSL_X86_64, etc., defines we set elsewhere, so
we can ensure they're consistent.
This required carving files up a bit. <openssl/base.h> has a lot of
things, such that trying to guard everything in it on __ASSEMBLER__
would be tedious. Instead, I moved the target defines to a new
<openssl/target.h>. Then <openssl/asm_base.h> is the new header that
pulls in all those things.
Bug: 542
Change-Id: I1682b4d929adea72908655fa1bb15765a6b3473b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60765
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
2023-06-12 18:11:13 -04:00
|
|
|
${PROJECT_SOURCE_DIR}/include/openssl/asm_base.h
|
|
|
|
|
${PROJECT_SOURCE_DIR}/include/openssl/target.h
|
2018-09-13 16:37:28 -05:00
|
|
|
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
|
2017-04-04 14:21:43 -07:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
add_library(
|
|
|
|
|
bcm_hashunset
|
|
|
|
|
|
|
|
|
|
STATIC
|
|
|
|
|
|
|
|
|
|
bcm-delocated.S
|
|
|
|
|
)
|
|
|
|
|
set_target_properties(bcm_hashunset PROPERTIES POSITION_INDEPENDENT_CODE ON)
|
|
|
|
|
set_target_properties(bcm_hashunset PROPERTIES LINKER_LANGUAGE C)
|
|
|
|
|
|
2018-09-26 14:21:25 -07:00
|
|
|
go_executable(inject_hash
|
2021-06-24 15:47:37 -07:00
|
|
|
boringssl.googlesource.com/boringssl/util/fipstools/inject_hash)
|
2017-04-04 14:21:43 -07:00
|
|
|
add_custom_command(
|
|
|
|
|
OUTPUT bcm.o
|
2022-07-26 07:12:34 +00:00
|
|
|
COMMAND ./inject_hash -o bcm.o -in-archive $<TARGET_FILE:bcm_hashunset>
|
2018-09-26 14:21:25 -07:00
|
|
|
DEPENDS bcm_hashunset inject_hash
|
2018-09-13 16:37:28 -05:00
|
|
|
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
|
2017-04-04 14:21:43 -07:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
# The outputs of add_custom_command cannot be referenced outside of the
|
|
|
|
|
# CMakeLists.txt that defines it. Thus we have to wrap bcm.o in a custom target
|
|
|
|
|
# so that crypto can depend on it.
|
|
|
|
|
add_custom_target(bcm_o_target DEPENDS bcm.o)
|
|
|
|
|
|
|
|
|
|
add_library(
|
|
|
|
|
fipsmodule
|
|
|
|
|
|
|
|
|
|
OBJECT
|
|
|
|
|
|
2019-05-30 16:13:39 -07:00
|
|
|
fips_shared_support.c
|
2017-04-04 14:21:43 -07:00
|
|
|
)
|
Remove global_target from build.
This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-05 13:44:26 -05:00
|
|
|
add_dependencies(fipsmodule boringssl_prefix_symbols)
|
2023-02-04 20:06:30 -05:00
|
|
|
target_include_directories(fipsmodule PRIVATE ../../include)
|
2017-04-04 14:21:43 -07:00
|
|
|
set_target_properties(fipsmodule PROPERTIES LINKER_LANGUAGE C)
|
2019-05-09 16:39:49 -07:00
|
|
|
elseif(FIPS_SHARED)
|
|
|
|
|
if(NOT BUILD_SHARED_LIBS)
|
|
|
|
|
error("FIPS_SHARED set but not BUILD_SHARED_LIBS")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
add_library(
|
|
|
|
|
fipsmodule
|
|
|
|
|
|
|
|
|
|
OBJECT
|
|
|
|
|
|
|
|
|
|
fips_shared_support.c
|
|
|
|
|
)
|
Remove global_target from build.
This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-05 13:44:26 -05:00
|
|
|
add_dependencies(fipsmodule boringssl_prefix_symbols)
|
2023-02-04 20:06:30 -05:00
|
|
|
target_include_directories(fipsmodule PRIVATE ../../include)
|
2019-05-09 16:39:49 -07:00
|
|
|
|
|
|
|
|
add_library(
|
|
|
|
|
bcm_library
|
|
|
|
|
|
|
|
|
|
STATIC
|
|
|
|
|
|
|
|
|
|
bcm.c
|
Reduce architecture detection in CMake.
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2023-01-25 10:03:53 -05:00
|
|
|
${BCM_SOURCES_ASM_USED}
|
2019-05-09 16:39:49 -07:00
|
|
|
)
|
Remove global_target from build.
This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-05 13:44:26 -05:00
|
|
|
add_dependencies(bcm_library boringssl_prefix_symbols)
|
2023-02-04 20:06:30 -05:00
|
|
|
target_include_directories(bcm_library PRIVATE ../../include)
|
2019-05-09 16:39:49 -07:00
|
|
|
|
|
|
|
|
add_custom_command(
|
|
|
|
|
OUTPUT bcm.o
|
2019-10-08 15:48:40 -07:00
|
|
|
COMMAND ${CMAKE_LINKER} -r -T ${CMAKE_CURRENT_SOURCE_DIR}/fips_shared.lds -o bcm.o --whole-archive $<TARGET_FILE:bcm_library>
|
2019-05-09 16:39:49 -07:00
|
|
|
DEPENDS bcm_library fips_shared.lds
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
add_custom_target(bcm_o_target DEPENDS bcm.o)
|
2017-04-04 14:21:43 -07:00
|
|
|
else()
|
|
|
|
|
add_library(
|
|
|
|
|
fipsmodule
|
|
|
|
|
|
|
|
|
|
OBJECT
|
|
|
|
|
|
|
|
|
|
bcm.c
|
2019-05-30 16:13:39 -07:00
|
|
|
fips_shared_support.c
|
Reduce architecture detection in CMake.
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2023-01-25 10:03:53 -05:00
|
|
|
${BCM_SOURCES_ASM_USED}
|
2017-04-04 14:21:43 -07:00
|
|
|
)
|
Remove global_target from build.
This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
2023-02-05 13:44:26 -05:00
|
|
|
add_dependencies(fipsmodule boringssl_prefix_symbols)
|
2023-02-04 20:06:30 -05:00
|
|
|
target_include_directories(fipsmodule PRIVATE ../../include)
|
2017-04-04 14:21:43 -07:00
|
|
|
endif()
|
