Change TARGET_ARCH_VARIANT from x86-atom to x86, for the reason
that atom-specific instruciton like "movbe" isn't "generic" to
x86 Android devices and x86 host running emulator-x86, which may
crash non-atom host in VT because "movbe" isn't supported natively.
Also revert previous fix in TARGET_linux-x86.mk which conservatively
disable "movbe" across the board
Change-Id: Ief93a3585566ffae558fcdc29741e6213a048d7d
Intruction "movbe" (move data after swapping bytes) is only available in
Intel atom. Disable it for more general x86 devices and x86 hosts which
run emulator-x86. Although emulator-x86 can support "movbe", most of
the time we want to run emulator-x86 with VT support for speed (with KVM
in Linux, or HAXM in Windows/MacOSX). The presence of "movbe" can crash
emulator-x86 in VT because non-atom host doesn't have it natively.
Change-Id: I86e037900ddcb8d544f92b8d8464c8627347e560
Added Mountain Lion to the list of versions which don't need ranlib
and don't need the pre-Lion linker flags
Change-Id: I0c785f0c66e324af9a209520c5a5b3c9bf7df0d5
Signed-off-by: Al Sutton <al@funkyandroid.com>
For Mac build, force_load the LOCAL_WHOLE_STATIC_LIBRARIES.
Mac has its custom linker. However, its linking rule for generating
shared libraries doesn’t take the LOCAL_WHOLE_STATIC_LIBRARIES
into consideration.
Change-Id: Ia6858bf6e2ebb334db8f3d0bdc71d7ecc0ef11c1
The cc and c++ compilers included in Apple's command line tools show some
unusual behaviour which causes the build to fail in several projects under
Xcode 4.3
This patch uses the gnu compatibility gcc and g++ compilers on OS X instead
to reduce problems, and generates an error when an llvm based compiler is
detected because they currently do not generate usable emulator executables
due to them not honouring global register variables.
Change-Id: I506c22dad3dcbd41df3c7672802a675d3655e262
Signed-off-by: Al Sutton <al@funkyandroid.com>
Enable relro / bind_now when compiling Android applications.
This marks certain regions of memory as read-only after linking,
making memory corruption security vulnerabilities are harder
to exploit.
See:
* http://www.akkadia.org/drepper/nonselsec.pdf (section 6)
* http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html
Stop using the custom linker script, which inhibits
relro / bind_now support.
Change-Id: Ie97ccdd2845886bbc2ba2fdd47eed0ff4b29b60b
Enable relro / bind_now when compiling Android applications.
This marks certain regions of memory as read-only after linking,
making memory corruption security vulnerabilities are harder
to exploit.
See:
* http://www.akkadia.org/drepper/nonselsec.pdf (section 6)
* http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html
Stop using the custom linker script, which inhibits
relro / bind_now support.
Change-Id: Iaebfbbb492299004f9da92b649985b6cd67d8c97
By default we build tool in 32-bit. This flag allow individual tool and its
dependencies to be built in 64-bit (eg. Emulator). Fixes to resolve 64-bit
porting issues (in other git) will be submitted seperately.
Change-Id: I486cf7ddac727d3c374ed890857d497c3a69e598
Everything that is based on ARMv7a should have a cp15 TLS register.
Enable it by default so it's not accidentally missed in newer board
configurations. In fact, this could be enabled for ARMv6 as well, but we
currently don't distinguish between ARMv5 and ARMv6 in the build system.
This can still be disabled by setting it to "false" in the board
configuration, but this shouldn't ever be needed.
Change-Id: Ic2918f32899c8bcfa482f92c98f5a192fa318470
With "-Wl,-rpath,@loader_path/../lib" the linker embeds
@loader_path/../lib as the target binary's rpath.
Here @loader_path means the path of the binary that initiates the
loading.
With "-install_name @rpath/libfoo.dylib " the linker runtime searches
libfoo.dylib in the binary's embeded rpath.
With this change you can call dlopen() without specifying the full path
of the shared library.
Change-Id: If9beb3f6f4642a377bff603bab5ba3fdb96211bf
Before this change, path of the install name is relative to the top dir.
That means you can execute dynamically-linked binaries only in the top dir.
With this change, you can execute dynamically-linked binaries anywhere.
Change-Id: I1c6441579ffb68505ea678296aceb2e66a6df1be
So we can have the same set of module names in different host arch
/ toolchain version combinations.
Change-Id: Iec66584bf3de92aedd71a59f9dbe74b6ed025b2e
This is the result of a recent conversation around the x86 ABI
and its relationship with how we build platform images. Briefly:
- We want to use feature-based macros like ARCH_X86_HAVE_$FEATURE
instead of relying on explicit compiler macros like -DUSE_$FEATURE
- We want to allow for other x86-based arch variants, e.g. if
someone wants to build Android for a CPU that doesn't support
the NDK x86 ABI. However, we need to ensure these are not
tagged compatible by mistake (see check at the end of TARGET_linux-x86.mk)
- There are several flags which use is dubious now that we have
a dedicated toolchain to build all the x86 stuff. Comment them
as 'to be considered for removal'. We'll do the proper checks
later.
Change-Id: I7768d7c34d73e274cbf4c09ae831b55280d6bb58
While building Android with latest host gcc, it causes the following
build error:
Install: out/host/linux-x86/bin/mkbootimg
host C++: obbtool <= frameworks/base/tools/obbtool/Main.cpp
<command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
<built-in>:0:0: note: this is the location of the previous definition
cc1plus: all warnings being treated as errors
In order to make build system happy, this patch does unset macro
_FORTIFY_SOURCE and then define it in host cflags.
Change-Id: Ic37a90f05081a2c3650b3335bc87e9e895900fb2
Compile all x86 programs on Android with -fPIE and -pie. This enables
PIE (Position Independent Executables), which helps protect Android
applications from exploitation due to memory management bugs.
Note 1: PIE *static* executables are not supported at this time and
require additional linker changes.
Note 2: This change compliments 026a85b129,
which was the exact same change, except for ARM.
Testing: Rebuilt the tree completely from scratch, and verified
that the system boots and basic functionality works in the emulator.
Change-Id: I990064c37da3d857e663b27f31fee05f689a2824
Compile all programs on Android with -fPIE and -pie. This enables
PIE (Position Independent Executables), which helps protect Android
applications from exploitation due to memory management bugs.
Stop using the armelf.x linker script. This script hard codes the
load address of the executable, defeating the position independence
PIE requires.
Note: PIE *static* executables are not supported at this time and
require additional linker changes.
Bug: 5323301
Change-Id: Ieafcc9c4f142495847e163881889d371a59d0878
While building Android with latest host gcc, it causes the following
build error:
Install: out/host/linux-x86/bin/mkbootimg
host C++: obbtool <= frameworks/base/tools/obbtool/Main.cpp
<command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
<built-in>:0:0: note: this is the location of the previous definition
cc1plus: all warnings being treated as errors
In order to make build system happy, this patch does unset macro
_FORTIFY_SOURCE and then define it in host cflags.
Change-Id: Ic37a90f05081a2c3650b3335bc87e9e895900fb2
We used to do that unconditionally but that caused lots of spurious
warnings in gcc-4.4.x about an unrecognized gcc option.
Change-Id: Idb5118b069871859e07a7efa04914ab6ed0b1372
This is used by debug tools to find symbols for the stripped binary.
Adds ~70 bytes to each DSO, ~25000 bytes total, which is about 0.01% of the
system image.
This change only affects -eng and -userdebug builds, and does not affect -user.
Change-Id: I0c92a9e09fbc97184dea66813923568cbcc2a3fe
"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
Review and clean-up of both compiler and linker flags
to ensure proper usage and consistency for images, toolchain,
SDK, and NDK.
Change-Id: Ife75c32cd49b32345712dee28fa5f2283069a90e
Signed-off-by: Mark D Horn <mark.d.horn@intel.com>
Author: Bruce Beare <bruce.j.beare@intel.com>
Set LOCAL_GROUP_STATIC_LIBRARIES := true to group the static libraries,
in case we need gcc flags "-Wl,--start-group" and "-Wl,--end-group" to
fix circular references.
Change-Id: I03c4901670112fcdd2bb0fe660b6924e5776fcf8
Bruce Beare