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>
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
