The current 32-bit configuration for generic x86_64 targets inherits some
variables (SSE4 support) from the 64-bit configuration, and overrides
the make variables used for other configurations (SSSE3). Ideally, these
would be using different variables, but until then, unify the
configuration for x86_64 targets so that everything is consistent.
Bug: 28694691
Change-Id: I47e67299d4c632e7491d7e73dc0fc6480ef08006
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
We removed code and variables related to running dx on classes.jar in
this change. Also removed target emma rules (but kept the emma rules for
host java libraries), for it's now done by Jack.
We still support to build classes.jar (and javalib.jar for static Java
libraries) using javac, because tools like javadoc need class files as
input.
Removed the obsolete install-dex-debug.
Bug: 27400061
Change-Id: If0bcdfe62cb181a98754fb0dbe1c12c92e38d3e8
Soong uses the copy of `ar` in the OSX SDK instead of the wrapper in
/usr/bin/ar. /usr/bin/ar appears to be a thin wrapper that looks up the
current SDK and passes execution to it. Soong does this so that it can
actually set up a dependency on the tool.
Change-Id: Ia4e4fbe3287539933fa98a1354c3ccee91f4d552
Build binaries usable on older machines even if older SDKs are not
installed. Older SDKs can no longer be installed on newer Xcode
versions.
Change-Id: I0c9f2534466a127a19107820879c2856bfac0076
We've been including the system libc++ headers even if we're building
against our version of libc++. Stop doing that, and only add the headers
to our path if we're using the system libraries.
If nothing is specified, on recent OSX versions, libc++ is the default
c++ library instead of libstdc++. We've been explicitly including the
libc++ headers on all versions, but that breaks old versions. Force us
over to libc++, since the system libstdc++ does not support C++11, and
libc++ is still supported on our oldest version (10.8).
Change-Id: I1fccee8da0f425e10ccc9d3247ed40664eb6ada0
/Developer was removed in Xcode 4.3. Our minimum SDK version is 10.8,
which implies at least Xcode 4.4, and our documentation requires
Xcode 4.5.2.
Change-Id: Ib343df6ded6e98222d8ee2e542e1f3fadd2b1397
Sandy Bridge actually doesn't have all of these options. For example AVX is only
available on the higher-end SKUs (not on Celeron G550).
Change-Id: Ib595a9a6b464626d0c88525c6aaa4d69176645cc
* When WITH_STATIC_ANALYZER is set and non-zero, and clang compiler is used,
call new clang ccc-analyzer or c++-analyzer.
* Otherwise, if WITH_SYNTAX_CHECK is set and non-zero,
call compiler with -fsyntax-only.
* Replace "--sysroot=path" with "--sysroot path", to work with ccc-analyzer.
* ccc-analyzer executes the original compilation command to generate
object files before calling clang with --analyze to do static analysis.
* When clang is called with --analyze, macro __clang_analyzer__ is defined.
BUG: 13287788
Change-Id: I5edb25b52998d871385dd000778db2ce83224078
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
This change enables build rules to specify:
LOCAL_JAVA_LANGUAGE_VERSION := 1.8
to enable -source 1.8 -target 1.8 for javac and
equivalent flags for Jack.
Bug: 26753820
(cherry-picked from commit cdfbe4a852)
Change-Id: I361c99dd599e7b4a041f02c9562e461da2b0502e
Bug: http://b/26524325
Bug: http://b/25282907
The latest Clang/LLVM requires Vista APIs in order to execute, so we
need to bump the minimum required Windows version for our host tools.
Change-Id: Ic1a760bc240060f5de39ce3a68484886021ff3d9
Turn back on ld.gold and W-l,--icf=safe for
aarch64, now that the prebuilt ld.gold has been updated
with support for reloc 311/312 (fixed upstream, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19042)
Bug: 25642296
Bug: 26153840
Change-Id: Idceb357a48d9da4eec38ab8f2103245d500622ae
Some projects are still built with our host GCC 4.8, which doesn't
support -fstack-protector-strong. The combo .mk files are used by
GCC and clang, so it's not safe to turn on -fstack-protector-strong
there. Instead, do it in the clang-specific .mk for now.
We can clean this up when elfutils (the last code built for the host
with GCC that I'm aware of) is built by clang. We'll be able to
remove the host GCC prebuilts too!
Change-Id: I314b9eab071c132a8e2cb8cc779a75ae8abb12e2
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: I2fb7f0bfccbfa5d22ca8858309a133469edbc7b6
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
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: I3ce7a73c5cf36eba5c74df37367f3d3475b0a4ed
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: I55a9fdbf5777ccdeed9f2e9a23c73bb94ad7b646
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: I97a2187cebac64e3b9f22b691d4676b6da083ebd
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
[Second attempt, this time with updated mac prebuilt]
Switches default linker from -fuse-ld-bfd to
-fuse-ld=gold, and enables -Wl,--icf=safe. This
changes reduces /system/lib64/*.so text size
by about 2% for N9.
Change-Id: I587075aae9d70cb6b16e55dc9cd1052580ac2626
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
Causes build failures on Darwin.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: warning: cannot scan executable section 5 of out/target/product/flounder/obj/SHARED_LIBRARIES/libdl_intermediates/libdl.o for Cortex-A53 erratum because it has no mapping symbols.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: warning: cannot scan executable section 8 of out/target/product/flounder/obj/SHARED_LIBRARIES/libdl_intermediates/libdl.o for Cortex-A53 erratum because it has no mapping symbols.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: warning: cannot scan executable section 11 of out/target/product/flounder/obj/SHARED_LIBRARIES/libdl_intermediates/libdl.o for Cortex-A53 erratum because it has no mapping symbols.
prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/ld.gold: error: treating warnings as errors
This reverts commit 127d110172.
Change-Id: I1d3de90f5ae777b66a8f94fbcc9ccde8a9e3001c
Switches default linker from -fuse-ld-bfd to
-fuse-ld=gold, and enables -Wl,--icf=safe. This
changes reduces /system/lib64/*.so text size
by about 2% for N9.
Change-Id: I0ef2483e1c47c34e63292dad6f6bf532359b733e
gcc color diagnostics stopped working when the flag was moved to
TARGET_GLOBAL_CFLAGS, as that gets overwritten by combo/select.mk. Put
it back in COMMON_GLOBAL_CFLAGS, and then let the windows build filter
it out, similar to the way clang deals with unknown flags.
Change-Id: I2db221edb893d81f199494e7515d1b9282c12fae
The darwin version doesn't have a trailing slash. The common case is to
append a path to it:
$(HOST_TOOLCHAIN_FOR_CLANG)/lib/...
Which means we end up with two slashes.
Change-Id: I74e88924ecfd092c5f7871e188ede0aab29cf65b
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
