It was previously a warning to set an incorrect ARCH_VARIANT
when CPU_VARIANT was set to a cpu for which we knew the arch.
Make it an error, as there are no offenders in the tree.
Re-structure the code to make it a little clearer when you get
a default and when you get an error.
Test: build_test
Change-Id: I5821a8162a59e8c2aed2370068f9eb656ced9d99
Newer cores are implementing armv8-2a ISAs.
Enabling 2nd arch. variant to support for new type of cores.
Test: set TARGET_2ND_ARCH_VARIANT := armv8-2a, build without warnings and not ignore armv8-2a
BUG: 118414869
Change-Id: I1cd64ab0ad9b253ec3d109ebd1dbc7882011ce77
This architecture only existed for unbundled use, but even the NDK is
removing support in their r17 release, so just remove support for it.
Test: build/soong/build_test.bash -only-config
Test: check buildserver configs, I don't see anything still using armv5
Change-Id: Ic183b510c9ada94438bd4cc2b9362fa438a29ced
This reverts commit 7de79cbeaf.
Fixed CTS build issue by adding -march=armv7-a in cts/tests/tests/os/jni/Android.mk since the library built here needs/uses instruction (swp) obsolete in ARMv8.
Bug: 64964151
Test: lunch aosp_arm64-userdebug; make -j cts
lunch aosp_x86-userdebug; make -j cts
lunch aosp_sailfish-userdebug; make -j cts
lunch aosp_bullhead-userdebug; make -j cts
Change-Id: Ic3a121600da8e2a9a2d5176b9680cd18ce457959
Overwrite TARGET_(2ND_)ARCH_VARIANT as armv8-a if
TARGET_(2ND_)CPU_VARIANT is set to some known armv8-a core like
cortex-a53, cortex-a73, kryo, denver64 etc.
For clang, -march is ignored if -mcpu is set to specific core so this
change doen't impact the objects built for armv7-a-neon/some_armv8_core
since it's treated as armv8-a/some_armv8_core.
Bug: 62895439
Test: Built modified aosp_arm64 with armv8-a as its TARGET_2ND_CPU_ARCH
and generic as its TARGET_2ND_CPU_VARIANT successfully.
"lunch hikey-userdebug; make" and verify TARGET_2ND_ARCH_VARIANT
is overwritten.
Change-Id: If4260cf397783b5f56c4fd432615f4676429a1d3
These are all either recently unused due to the removal of CFLAGS/etc,
or have been exported by Soong and are no longer necessary.
Change-Id: I5930d43fda21acc8202b3d8ea010fbefb6ae4cf1
At the beginning of every build, Soong has exported its version of these
variables, and has been ensuring that when sorted, the result is the
same. So these variables all have the same flags of the Soong ones, but
may be in different orders. We don't believe any of the remaining order
differences matter. As we remove the Make definitions, the exported
Soong variables will take over.
This only removes lines that change one of these variables:
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CPPFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_LDFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CPPFLAGS
[2ND_][CLANG_]HOST_GLOBAL_LDFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CPPFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_LDFLAGS
Many other variables are unnecessary now too, but those will be removed
in another change. For those we can ensure the build.ninja file does not
change, but we expect it to change here due to the ordering differences.
Change-Id: I0bd0778706d02ee27b2784dd8dc6b2c71d37bd3a
We never use it for host modules, and all the target configurations use
the same linker argument. This matches Soong.
Change-Id: Ibcba9a4ce340c7a12306d1fee620a04027c0e292
These have all been strictly checked by Soong, so the values currently
match. Just remove them so that the make variables exported by Soong
will take over.
This also removes some of the GCC reconfiguration, since we haven't
implemented that in Soong. If it becomes useful in the future, we'll
implement it there.
Some things like TARGET_TOOCHAIN_ROOT can nearly be removed, but are
used before the Soong-exported make_vars.mk is loaded. In that case,
added to the clang cflags, so it can be removed once the cflags are
removed.
Others, like LLVM_PREBUILTS_VERSION are loaded even earlier -- in
envsetup.sh before we've even configured Soong. So for now, keep the
Make definition, and continue ensuring it's the same as the Soong
version.
Change-Id: I554b27062ac43610828a8c06d640d919a2dc21ca
Instead, use the libgcc/libatomic/libgcov from the static libraries dir,
which is provided by Soong. Copy the libraries using the Soong script if
Soong is disabled - this can be removed once USE_SOONG is removed.
Change-Id: Iad2ad20ad5c3cfc48bf1e46e594a482609098d7a
This flag was added to stop a GCC 4.4 specific warning. Since we've
upgraded, this flag is no longer necessary. It's already stripped for
clang builds, and I found no instances in the logs after removing it.
Change-Id: If5316d2eb8066dc43d7af7aebc7e4920b4ada192
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: Iccc20852db8a5e4dd9792f9da6d5e325fc59b0a5
Currently, if a version script is passed to the linker (using
-Wl,--version-script,...), it is used to limit symbol visibility and
assign symbol versions. But if a symbol is listed in the version script
but is not present in the binary, no error or warning is given.
Pass -Wl,--no-undefined-version to the linker so that it verifies all
(non-wildcard, C) entries in the version script match symbols in the
binary.
Change-Id: I65878931ab61124ae75e2c738cc733adfb107afc
When a shared object is rebuilt, all dependent libraries and
executables are rebuilt. Such rebuild is unnecessary when there
is no interface change. With this patch, .toc files will be
generated for all .so files. The rule which generates .toc files
has ninja's restat=1 and .toc files are not changed ninja won't
rebuild dependent targets.
Performance:
$ m && touch bionic/libc/stdio/stdio.c && time m
Before: 1m03s (2563 targets)
After: 21s (90 targets)
Bug: 24597504
Change-Id: Ia5dd950273d143f4e99eee8bef7478f1a94cd138
There will only be a very small set of non-uapi headers. This is
mostly being done for the scsi headers since the kernel has not
made uapi versions of all of them.
Change-Id: I44904b07ff96de918dc5fcab4e5f117a34cb2a87
USE_MINGW=1 mm didn't work in directories that contained target modules
because the build system would use the Windows locations and extensions
when trying to find the host GCC prebuilts. Windows is the target OS,
not the OS we're building from.
Change-Id: Ic994fed15388d0c7d393f71ba28fe7afdc659f5c
Add replocation-packer step for dynmic executables.
Enable it by default for arm and arm64 platforms.
Bug: http://b/18051137
Change-Id: I0c88fd31595bcea62a087f219acb9ecf9c80f2e5
We want to store the symbol information for all android binaries in a global database.
* We ingest unstripped binaries into the global database
* When we collect address data from device (e.g. instruction pointer address), we want to lookup its symbol information through the global database. The key of the mapping is a unique build id, which is the same between binaries on device (stripped) and unstripped binaries.
After applying this patch, the system.img size increases by 0.0047% (16.3KB).
Change-Id: Id92faf2951f43a30947e8d2b690c1af6bf7e3f54
Previously, there was one generic definition for each of the
transform-o-to-* functions in definitions.mk, and one target specific
one in each combo/TARGET_*.mk. The generic one was entirely unused,
and the target specific ones were all nearly identical.
Changing anything in these functions was tedious at best, and often
error prone. The differences between any 32-bit arch and its 64-bit
equivalent were restricted to the name of the linker, and the ARM and
MIPS definitions were identical. The few differences between ARM and
x86 looked to be compatibility for an old (ca. 2008) toolchain issue
with --gc-sections, and a bug (LDFLAGS coming first rather than
later).
To simplify things, I've moved the definitions for these out of
combo/TARGET_*.mk and back into definitions.mk. The differences
between ARM and x86 have been scrapped. Anything that really does
still need to be target specific can be handled as I have the linker:
add a TARGET_FOO variable to the given target and then add it to the
generic definition.
Change-Id: I54dc1bffc32ac39f27f0b87247dd6a6dbaf0b162
The compiler run-time library should always be the _last_ thing linked
when building static executables. This was being done correctly for
libgcc, but not when using compiler-rt.
Change-Id: I0689dc35f55caad2fe74c0cbb4cbe3008ded349a
To enable building with coverage, the environment variable
NATIVE_COVERAGE must be set to true.
Set `LOCAL_NATIVE_COVERAGE := true` to generate coverage information for
a given component.
This is currently not supported for clang (b/17574078, b/17583330).
If static library A is included in a binary B (dynamic or static
executable, or shared library), and A is built with coverage
information, B is required to link with libgcov.a. Since the make does
not offer a good way to track this dependency, link libgcov.a even if
LOCAL_NATIVE_COVERAGE is not set (but still guarded by NATIVE_COVERAGE).
This ensures that all of the libgcov dependencies will always be
resolved, and causes no change in the resulting binary if coverage is
not used.
Bug: 10134489
Change-Id: Id5a19f2c215e4be80e6eae27ecc19b582f2f6813
Preparing for migration from stlport to libc++. STL selection is done
with LOCAL_CXX_STL (valid values are default, none, libc++,
libc++_static, stlport, stlport_static, bionic).
The selection of the STL is as follows:
if LOCAL_CXX_STL == 'default'
ifdef LOCAL_SDK_VERSION
Use whatever STL the other NDK options have selected.
else
Use bionic's libstdc++ for target, GNU libstdc++ for host. This
is compatible with the existing build options.
endif
else
if LOCAL_CXX_STL == 'stlport'
Use stlport.
else if LOCAL_CXX_STL == 'libc++'
Use libc++.
else if LOCAL_CXX_STL == ''
Don't use any STL.
endif
endif
Bug: 15193147
Change-Id: If712ba0ae7908d8147a69e29da5c453a183d6540
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
* Explicitly check BUILD_FDO_INSTRUMENT and BUILD_FDO_OPTIMIZE with true
* Remove unnecessary target_libgcov
* Update the profile collection path on device so that most app can have write access
Change-Id: I5c1915a12ea37b2cb3c76a27e7104e47ad636928
