GitLab

"lunch sdk-eng" on cygwin tries to use a gcc.exe from the
prebuild arm toolchain, but it doesn't exist. This prevents
from setting variables to point on a gcc toolchain if there
is none for the given arch.

Change-Id: I3b72220663687f9fdaacc050899aef00632f2c3c

Added LOCAL_NO_CRT to enable building executables that do not link
to the C runtime library.

Removed support for LOCAL_MODULE_SUBDIR since it was broken
and unused.  (Was going to use it but ended up using LOCAL_MODULE_PATH
instead.)

Change-Id: Ifed4ffe17003d90370c711ea6606e2b75e841dee

Change-Id: I1d42d0f0dee361b98403bc87296dcbc37484ebcb

Added LOCAL_NO_CRT to enable building executables that do not link
to the C runtime library.

Removed support for LOCAL_MODULE_SUBDIR since it was broken
and unused.  (Was going to use it but ended up using LOCAL_MODULE_PATH
instead.)

Change-Id: I3b6f5ab7e5ae6aaa7119899adccece2b4ab1cbb3

Change-Id: Ib7e17bbb4682caecce5812e63de872b676403d64

Change-Id: Ifc628c67b5fa142cec59187f89f2d39df81160b9

Change-Id: Ide41aeddc44ca05d85a36035c2d55ea453cfd216

The purpose of removing global inline options is to give
compiler the opportunity to do inline optimizations and inline
tunings for Android native codes.

By removing these global inline options now, the size of
almost all native libraries are reduced. And there is no
noticable performance degradation on webkit, gcstone and
skia benchmarks.

Change-Id: I31e71f51e4f29fa6286fddb89e9eab227581c7b3

Bug: 3117632
Change-Id: I2fb58e7093984d18d2d2d21edf687206f4ddab31

Change-Id: I17a1ed13af6d4955a636ad429917b683ac59a947
Signed-off-by: Dima Zavin <dima@android.com>

androideabi target is already in upstream GCC. The arm-linux-
androideabi toolchain can be built directly from upstream GCC.
Switching from old special tailored arm-eabi toolchain to the new
arm-linux-androideabi toolchain make us closer to the opensource
community and friendly to all toolchain developers.

kernel still uses arm-eabi toolchain. So we add arm-eabi toolchain
path to PATH.

The arm-linux-androideabi-4.4.x toolchain is built with the same
source as the latest arm-eabi-4.4.3 toolchain except for the
target change patches.

Change-Id: I1e5f2fe2faeee08f913f37e0ba93e84d2654a8ff

between libc, libc_nomalloc and libgcc. When building with upcoming
arm-linux-androideabi toolchain, Symbol raise is needed by libgcc.a
and defined by libc.a or libc_nomalloc.a.which.

This patch groups libgc.a, libc_nomalloc.a and libgcc.a together, which is
a minimal group to solve this problem.

Change-Id: I27ed78c495dc53c1db7b302da8704f5e478ad893

Bug: http://b/issue?id=2811253
Change-Id: Iabd4ab8b3d7236dffe89f1939e1142e882944026

Change-Id: I61137f5bb123dc5f610af9928ed3debdf85ba74d
Signed-off-by: Bruce Beare <brucex.j.beare@intel.com>

Change-Id: I49af3366262bebe12dacfebe99ec742b79bf9d84

This is necessary to ensure that dlclose() will properly call C++
destructors for the static objects within the shared library.

Change-Id: Ieb056042f9cda7ab120eb770b21f365cd6d64a66

gcc-4.4.3 toolchain is based on fsf GCC-4.4.3 with numerous patches.
It reduces 3.65% code size than the prebuilt gcc-4.4.0 toolchain,
and improves 3.4% performance on Android benchmarks.

The toolchain uses gold as default linker. With gold, the toolchain
further reduces 1MB system image.

Change-Id: I55eb4df185f2932e71498fcc28428e4d1b175393

Change-Id: I6305e93515e57462e7c57af0cc41a659e4190696

Security hardening: don't allow code to compile which
uses format strings in an inappropriate way.  Make format
string compiler warnings into errors.

Change-Id: I1461dad589a2416420fd84ccf765983e859eea8a

Add -Wa,--noexecstack and -Wl,-z,noexecstack as default
flags when compiling applications.  This enables NX
protections, which prevent code from executing on the
stack or heap.  NX protections can block a large number
of buffer overflow attacks, and is an important security
feature.

Change-Id: Iad4bab9f8664584ba6ce832a5318d07680d7a908

A package can define a LOCAL_LDFLAGS.  If a LOCAL_LDFLAGS
exists, it should come after the global LDFLAGS, to allow
the local flags to override the global flags.

Change-Id: I6e44c17949c1f11c808d0ed3f327d63fb51a1468

The only OS-ARCH combo that would have benefited from it
is linux-x86, but it explicitly used separate configurations
for the HOST_ and TARGET_ side of things.

This makes is clear which files are related to the HOST_
configuration and which ones are related to the TARGET_
configuration, and expands $(combo_target) to the only
possible/reasonable value that it could have had in every
file.

This also cleans up the simulator, by moving it in a single
place in TARGET_linux_x86 (since the only part that's special
is to use HOST_ settings even when building TARGET_ modules).

Change-Id: I2420eeb8cfe539f5807ec99cb3177ffb9f2476d5

The "set default variant to armv5te if none defined" in the ARM config
was applying to all architectures, but as it turns out only ARM builds
actually cared.  When I made a copy of the "set default" code to the x86
config, one or the other would win for builds that didn't specify a
variant.  Turns out x86 won, so sim and voles worked, but opal didn't.

i.e. if NDEBUG is defined, then SK_RELEASE will get defined in the skia config headers

Change-Id: I0fb7ffcfb9786f611e981d8f22f67a5ac8c9c405

Signed-off-by: Erik Gilling <konkers@android.com>

Move arch-specific definitions into core/combo/arch/arm/<variant>.mk

This is currently a copy & paste of the armv5te parameters.  I don't
know if there's a better way to encode this, or to what extent we will
need to specialize it vs. armv5te in a future build (e.g. to enable fp
instruction use in code gen).

Currently the only effect is to select the VFP-enabled mterp sources in
Dalvik.

Don't make the simulator default to debug mode.

Remove all global "debug" {C,CPP}FLAGS, which are no longer used.

Switch default ARM compiler to gcc-4.3.1 for Neon support.

armv4 was only implemented on StrongArm and Arm8 (See http://en.wikipedia.org/wiki/ARM_architecture)
and will be more difficult to support since it does not support the bx instruction.
armv4t on the other hand is used in a wide range of cpu:s.
armv4 is also not supported by bionic or dalvik, but armv4t is.

Thumb-mode is not yet enabled since there are some unresolved abi-issues.