x86_64 gcc exports malloc/free and co functions because they
are defined with visibility "default" somewhere in gcc builtins;
and vector d-tors for some reason. Switching to clang fixes
this problem.
Bug: http://b/24785482
Change-Id: I741503b4b446523e7ff3fb16de13ed99991fd0c0
This patch also fixes realpath for libraries opened directly
from apks.
Bug: http://b/21960914
Bug: http://b/21961857
Change-Id: I35ade661c87f1d448191f385811f6e9fd3cacf11
With this change, we only define the rules to create the symlinks in
this Android.mk but without attaching the symlinks to the module linker.
Instead the core build system will set up the dependency whenever a
module needs these symlinks.
Bug: 22850550
Change-Id: I36c58fd411f1c27f3f638b229699d7dc1d66abb2
Sorry, I undertested my previous change and these guys somehow sneaked in.
This only affects SANITIZE_TARGET builds.
Change-Id: Id6986d89fa3d4965339f7b6fe973e9db73b380da
Setup a /system/bin/linker_asan as a symlink to "linker".
Read the linker name from PT_INTERP, and if it is linker_asan,
switch default library lookup paths to the ASan set, which
starts with the path to the instrumented libraries
(/data/lib), followed by /system/lib as a fallback.
This ensures that ASan binaries prefer ASan libraries, when
available. This approach is way better then RPATH/RUNPATH and even
better than LD_LIBRARY_PATH:
- RUNPATH is per-DSO, while default paths are global.
- LD_LIBRARY_PATH is overwritten by android_update_LD_LIBRARY_PATH.
- neither RUNPATH nor LD_LIBRARY_PATH appear in
android_get_LD_LIBRARY_PATH which is used to build java.lang.path.
Having ASan libraries in java.lang.path is a good thing.
Bug: 22355945
Change-Id: I1d2791fbf5740618f18f71a3ae3d873714669d3f
GDB does not yet have support for compact branches, and is not able
to set a breakpoint on rtld_db_dlactivity(), which is compiled into
one JIC instruction. Unfortunately, We cannot turn off generation of
JIC compact branch. Instead, add unoptimized FP handling code, so GDB
will have something to land on.
Change-Id: Iddcf40ec018972398179018d049b8323fcd258b7
Add code to support loading shared libraries directly from within
APK files.
Extends the linker's handling of LD_LIBRARY_PATH, DT_RUNPATH, etc
to allow elements to be either directories as normal, or ZIP
format files. For ZIP, the ZIP subdirectory string is separated
from the path to file by '!'.
For example, if DT_NEEDED is libchrome.so and Chrome.apk is the
Android ARM APK then the path element
/system/app/Chrome.apk!lib/armeabi-v7a
would cause the linker to load lib/armeabi-v7a/libchrome.so
directly from inside Chrome.apk. For loading to succeed,
libchrome.so must be 'stored' and not compressed in Chrome.apk,
and must be page aligned within the file.
Motivation:
Chromium tracking issue:
https://code.google.com/p/chromium/issues/detail?id=390618
Bug: 8076853
Change-Id: Ic49046600b1417eae3ee8f37ee98c8ac1ecc19e7
Add basic general purpose memory allocator to
linker in order to enable usage of other libraries
like libziparchive.
Change-Id: I4a680ebb36ed5ba67c61249f81dba9f567808434
Must build this linker as a shared object.
A statically linked module does not load during init.
BUG: 18008984
Change-Id: I5f0411129024edcb9381c473ea4e741a075e9184
Make the request structure match the new structure found in debuggerd
code.
On 64 bit systems, make sure that the 32 bit compiled linker is contacted.
Bug: https://code.google.com/p/android/issues/detail?id=97024
Change-Id: I675b8ff222fcf836b05de4e9b5976ff91ca929bf
Previously we duplicated code in build/core/executable.mk and it's hard
to maintain. LOCAL_POST_LINK_CMD is a clean solution for this.
Bug: 17403674
Change-Id: I8c054bf782af68cf1f88b8d787a78ca74a7968b5
Use LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64 to build
linker and linker64. Set LOCAL_MULTILIB := both for consistency
with other rules of this type, although LOCAL_MULTILIB := both is
only consumed by executable.mk which is skipped by
linker_executable.mk. Duplicate the necessary new parts of
executable.mk.
Change-Id: I888e87cf125cfbcfdee6a55b6377d8bc5ce402ea
We don't need this on architectures other than aarch64, and
we're still investigating why we need it on aarch64, but it
doesn't seem unreasonable to have this flag set when linking
the dynamic linker anyway; it's clearly the intended behavior.
Change-Id: I4fa1b4ae543a818979934bf818eabac03bb9154f
Addition of support for AArch64 in the linker64 target.
Change-Id: I8dfd9711278f6706063e91f626b6007ea7a3dd6e
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
We don't need our own architecture macros; the standard ones will do.
This patch also fixes some __x86_64__ tests to be USE_RELA tests instead,
because they're not actually x86_64-specific.
I've cleaned up architecture-specific code slightly so where possible
all the code corresponding to a particular architecture is together.
This patch also fixes a bug in LP64 DT_PLTGOT handling, which should be
an error rather than falling through into DT_DEBUG! There was another #ifdef
bug where we'd only report unexpected DT_ entries on MIPS.
Change-Id: Id1d04e372611f641c1aa278a18e379f28af9eaf5
Like the new TODO says, though, do we need this at all? Wouldn't we be better
off just using the regular architecture-specific macros? This is a dynamic
linker, so there's never a possibility of cross-linking.
Change-Id: I7be6b8663f5e585c4024a49aae383430c86a3c1b
We had two copies of the backtrace code, and two copies of the
libcorkscrew /proc/pid/maps code. This patch gets us down to one.
We also had hacks so we could log in the malloc debugging code.
This patch pulls the non-allocating "printf" code out of the
dynamic linker so everyone can share.
This patch also makes the leak diagnostics easier to read, and
makes it possible to paste them directly into the 'stack' tool (by
using relative PCs).
This patch also fixes the stdio standard stream leak that was
causing a leak warning every time tf_daemon ran.
Bug: 7291287
Change-Id: I66e4083ac2c5606c8d2737cb45c8ac8a32c7cfe8
The linker is essentially a shared library, and incorporates
it's own copy of libc. Even though it's unnecessary, currently
/system/bin/linker is exporting various libc symbols (only to
apps which explicitly dlopen /system/bin/linker)
Add --exclude-libs,ALL, which tells the static linker to mark
all of the imported libc symbols as hidden. This reduces the
size of /system/bin/linker from 92K to 67K with no obvious
loss in functionality.
$ adb shell ls -l /system/bin/linker
-rwxrwxrwx root root 92260 2013-01-16 16:52 linker
$ adb shell ls -l /system/bin/linker
-rwxrwxrwx root root 67660 2013-01-16 16:49 linker
Documentation on exclude-libs can be found at
http://sourceware.org/binutils/docs-2.21/ld/Options.html
Change-Id: I4508287770e4b7a845def2e6b4af969f9c866c6a
