Atomic functions used in external/libcxx/include/atomic when compiled with Clang
will require intrinsic functions exist only for prescott or newer CPUs.
BUG: 17530542
Change-Id: I0c9660ed2ffa75b940981eb8165d88934b39aec5
We no longer need gcc for host builds, since those all run through clang. This
header include, however, triggers errors about SSE intrinsics by replacing
the more relevant include dirs that we should be using.
Change-Id: I26a949f0109de8e6e2d1f09cb8127be927549cc4
Yikes. Don't know how this slipped through code review.
I had actually mentioned a need for cleanup in this part of the build
system earlier, since the amount of duplication between
transform-o-to-* for each arch means we might fix things incorrectly
in one of them (as I've just shown). Similarly, code reviewers are
likely to skim each one after the first if they all look close enough
(which is presumably what happened here).
Change-Id: I9b85914510f0b114485021deb97f42740712aae5
LPAE indicates better instructions can be used when atomicity guarantees are
needed. However, LPAE's presence isn't advertised by clang/GCC. We fake an
ARM feature to advertise its presence on architectures where it is.
Also, add a TODO documenting that cortex-a15 is not the correct CPU variant
for krait.
Change-Id: I02a1248025c32d94eca0bc8a249dc524f1ac9c36
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
For ndk docs change, please refer to:
https://android-review.googlesource.com/#/c/110100/
Change-Id: I8428e7a979eb02441066aeeee43ce693d4d0dc8d
Signed-off-by: Alexander Ivchenko <alexander.ivchenko@intel.com>
Bug: 14416410
prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/x86_64-w64-mingw32
is the location for the checked-in hermetic mingw Windows compiler. This
removes our reliance on host mingw when building with "make win_sdk".
Change-Id: I1f9bbb85912d9855be32f9cab4bdfd12d6d3246c
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
Remove -msse2 for x86 (-mssse3 should be provided by the compiler).
Remove -fPIC (compiler provides by default).
Remove -fno-inline-functions-called-once.
Change-Id: Ibb29934224c4eedfff926dc72c3b6342c1861ac9
(cherry picked from commit 388dce3192)
Remove -msse2 for x86 (-mssse3 should be provided by the compiler).
Remove -fPIC (compiler provides by default).
Remove -fno-inline-functions-called-once.
Change-Id: Ibb29934224c4eedfff926dc72c3b6342c1861ac9
* commit '33f14e60729443b8c3958ea4246c914fc18891f9':
Add missing flags to x86 (both 32- and 64-bit) arch variants. Delete x86_64-atom.mk as we don't support 64-bit on old Atom.
We should probably try to remove these files completely, but this at
least takes care of the stuff that's completely obsolete.
Change-Id: Ic71b7b491c119963068294e258dc6afe5a45b40d
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
(cherry picked from commit 4803ce2696)
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
Add mips64r6 target and corresponding mips32r6 target.
Defaults remain as mips64r2 and mips32r2.
Apply -FP64A codegen subsetting to mips32r6 only.
Access FR=0 odd-numbered 32-bit float regs only via
double-prec even-numbered regs, not by single-prec ops.
(cherry picked from commit 6bab974cdc)
Change-Id: I447337ce56c15e86cec505d68a6b45294fc3ba77
Use 4.9 mips64el toolchain for both 64- and 32-bit builds.
Tell ld when 32-bit links are required.
Override 4.9's changed defaults for mips floating point
register use, to get same assembler rules as 4.8 and earlier.
Also: drop unused soft-fp build targets, cleanout redundant
compiler options, and remove extraneous Android.mk file.
(cherry picked from commit 6670e24aed)
Change-Id: I34d2f8fc6113c9d1670e3acff1aff48634b9fe1b
Delete x86_64-atom.mk as we don't support 64-bit on old Atom.
Change-Id: I0b9ab61cd9b840f32c30059cb3ba9704c733c42a
Signed-off-by: Varvara Rainchik <varvara.rainchik@intel.com>
* 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
This patch ensures the build system uses the prebuilt gcc-4.8 toolchain
when building host Linux binaries, instead of the gcc-4.6 one.
Change-Id: I7b449650714ba4314a780827e0243f2af40ec82c
Add mips64r6 target and corresponding mips32r6 target.
Defaults remain as mips64r2 and mips32r2.
Apply -FP64A codegen subsetting to mips32r6 only.
Access FR=0 odd-numbered 32-bit float regs only via
double-prec even-numbered regs, not by single-prec ops.
Change-Id: I1740a6c658304b6c41242be58d68753e6f171658
Use 4.9 mips64el toolchain for both 64- and 32-bit builds.
Tell ld when 32-bit links are required.
Override 4.9's changed defaults for mips floating point
register use, to get same assembler rules as 4.8 and earlier.
Also: drop unused soft-fp build targets, cleanout redundant
compiler options, and remove extraneous Android.mk file.
Change-Id: I86f1075266349edb2b08a7709b9f5472d8cfda32
Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2
mechanisms to judge if it's 64-bit build;
Remove the unnecessary 32-bit host variables.
Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
-fPIC is more restrictive than -fPIE, but when "-fPIC -fPIE" used together
the latter overrides. It may lead to issues when building DSO where
-fPIC and not -fPIE is required.
For executables -fPIE -pie shoudld be added and it's fine to override
-fPIC as it is done now.
The reason why we don't have these issues so far is probably related to
-Bsymbolic added by default. But any attempt to remove it reveals these
problems:
https://android-review.googlesource.com/#/c/98061/
Change-Id: If0f10628b7cc41e564221a7a37298f7d65f859a8
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
This is causing issues when tools like asan try to wrap calls like
malloc. See the referenced bug for more details.
Bug: 15432753
Change-Id: I15e8eab5b773afd02dc14c78500cf8246a617718
The futex wrappers and memcmp16 are no longer available to anyone.
No one was checking for the existence of the SA_NOCLDWAIT constant,
and even if they wanted to, they could just check directly.
Change-Id: If8ac6c2617b76b23a2450f58fc03453f7f82a61f
The previous commit 994c84fb virtually disabled ccache, due to the
deferred evaluation of CC_WRAPPER/CXX_WRAPPER.
Change-Id: Ie0d70a23a55190bd9b24b72edc9158b6976e1d5d
This is to make it possible to wrap the compiler invocations with
custom wrappers (e.g., distcc/goma) by setting the CC_WRAPPER,
CXX_WRAPPER, JAVAC_WRAPPER variables in the build environment (without
having to know in advance the path to the compiler)
(cherry-picked from AOSP 994c84fb40)
Change-Id: Ide800c24f0c2ebbb1cfb358bd8f99ec8a9d41253
This is to make it possible to wrap the compiler invocations with
custom wrappers (e.g., distcc/goma) by setting the CC_WRAPPER,
CXX_WRAPPER, JAVAC_WRAPPER variables in the build environment (without
having to know in advance the path to the compiler)
Change-Id: Ide800c24f0c2ebbb1cfb358bd8f99ec8a9d41253
Projects using stdatomic.h needs libatomic.a in case compiler can't
expand all __atomic* intrinsics. eg, __atomic_is_lock_free in
armeabi/mips.
Adding libatomic.a globally makes more sense than adding
"LOCAL_LDLIB += -latomic " in each project including <stdatomic.h>.
Projects don't need atomic operations won't get redundant DT_NEEDED
entry because libatomic.a is not a shared library.
Change-Id: I81dbf524544c848e667e18ab5eeabff75b5063ef
_extract-and-include-single-(host|target)-whole-static-lib was written such that
only the first file of a given name would be extracted and included into the new
library. This patch iterates over each identically named archive member,
extracts them individually, and adds them to the new archive.
Bug: 15110069
Change-Id: Ia08c7be6f40bfc8403908a8808898ada479099b1
GCC: 4.9 (which supports -fstack-protector)
Binutils: 2.24 (which supports gc-sections)
GDB: 7.7
NDK libraries are still picked up from prebuilts/ndk/*/4.8/*
GCC has been patched to disable codegen for calling
__cxa_throw_bad_array_new_length.
Source code has been sync'ed against the 2014-05-14 snapshot which
contains many important fixes (devirtualization, codegen, ...).
Change-Id: I43229360ad0132193d5208cb0d1acba55084853c
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
GCC know a few pre-defined paths (relative to its location) to
search for headers, libraries, program, etc. By default GCC prefixes
its own path(argv[0]) and calls realpath() which result in absolute
path with all symlink, . and .. removed.
It's usually good to have canonicalised paths, but absolute paths
in *.d file can cause unnecessary relinking when stale entries
in ccache cache hit
Add -no-canonical-prefixes (gcc>=4.6) and
-fno-canonical-system-headers (gcc>4.6) to disable realpath() on
prefixed paths
Change-Id: I58d739e61fb013015fb05a9c98b2132b307f915a
Some printf/scanf functions in Windows aren't C99 compatible.
Define __USE_MINGW_ANSI_STDIO for mingw compiler to use it's own set of
replacement libraries which are more C99-like.
Change-Id: I51dfa582971ec0487409067e8bb7fe3a44577b93
* Currently the flag conflicts with one seen in hardware/qcom
rename to avoid issues.
Change-Id: I876fcd6a254f349dc5260509bcddb0367a7d49d8
Signed-off-by: Nick Reuter <nreuter85@gmail.com>
Use LOCAL_LDLIBS to link against prebuilt libraries (such as NDK
libraries).
Previously LOCAL_LDLIBS only applies to host modules and the behaviour
confuses users.
Change-Id: I515546d7b59ef54e8ef09050eb58ec63534c9291
This is used for Baytrail targets.
Change-Id: I5a2fa6dbb8217a326ee09f5ea434885718ab3f0c
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
GCC: 4.9 (which supports -fstack-protector)
Binutils: 2.24 (which supports gc-sections)
GDB: 7.7
NDK libraries are still picked up from prebuilts/ndk/*/4.8/*
GCC has been patched to disable codegen for calling
__cxa_throw_bad_array_new_length.
Change-Id: Ie0bf38357c0cf3d265d8b5dd3c2b8a8fd83b1de1
The "-maarch64linux" switch is needed before aarch64-*4.8 is rebuilt with
backport of upstream patch, see https://android-review.googlesource.com/#/c/91099/
The existing ld.bfd is fine because it's configured to support
aarch64linux only. ld.mcld (see https://android-review.googlesource.com/#/c/91047)
needs explicit emulation switch because it supports multiple targets
Change-Id: Idc1a491c5722ea9e26db917b667b1000bccc1f60
GCC: 4.9 (which supports -fstack-protector)
Binutils: 2.24 (which supports gc-sections)
GDB: 7.7
NDK libraries are still picked up from prebuilts/ndk/*/4.8/*
GCC has been patched to disable codegen for calling
__cxa_throw_bad_array_new_length.
Change-Id: Ie647fc4c6b227d6bee792f04d5c2f02eb0099559
Chih-Hung Hsieh