Remove the hand-collated ones, and switch to a script that pulls the
copyright headers out of every file and collects the unique ones.
Change-Id: Ied3b98b3f56241df97166c410ff81de4e0157c9d
Also make the errors more readable, since none of us seemed to know
what they actually meant. The new style is still as verbose as the
old, but that's probably necessary in the absence of chained exceptions
in C. Here's what you'd see if you try to boot after removing
libsurfaceflinger.so:
32267 32267 E AndroidRuntime: java.lang.UnsatisfiedLinkError: Cannot load library: (linker.c:1629, pid 32259) soinfo_link_image: could not load library "libsystem_server.so" needed by "libandroid_servers.so"; caused by (linker.c:1629, pid 32259) soinfo_link_image: could not load library "libsurfaceflinger.so" needed by "libsystem_server.so"; caused by (linker.c:709, pid 32259) load_library: library "libsurfaceflinger.so" not found
This patch also fixes almost all of the compiler warnings.
Change-Id: I64bb59aed6d4e039c15ea45be2367f319ef879f8
Given that _elf_lookup (and thus, _do_lookup) cannot possibly return an
undefined symbol (due to the check for SHN_UNDEF in _elf_lookup), there's
no need for spurious checks for SHN_UNDEF on its return value.
Conflicts:
linker/linker.c
Change-Id: Ic73cf439924b45f72d4d9ba3f64a888c96cbbd9b
GDB needs the runtime linker's base address in order to
locate the latter's ".text" and ".plt" sections, for the
purpose of detecting solib trampolines. It also can
potentially use this to calculate the relocated address
of rtld_db_dlactivity.
Bug: http://code.google.com/p/android/issues/detail?id=34856
Change-Id: I63d3e7ae4e20a684ceb25967f2241e7d58dd685d
Signed-off-by: Ryan V. Bissell <ryan@bissell.org>
Since linker is built with -fvisibility=hidden rtld_db_dlactivity()
if hidden from gdb. Unhide it otherwise gdb may not know linker
activity and rescan solib
Change-Id: Ia8cd8d9738c6ea5696ba2ef0ebf2cf783f9ca70a
Use the functions in linker_phdr.c to load the PT_LOAD segments
in memory, and toggle their mapping's writable protection bit
as needed. In particular:
- when loading a library, load the segments then unprotected
them to allow relocations to work.
- when relocating the linker of the executable, unprotect
the segments loaded by the kernel to make relocations work
too.
- after all relocations are done, re-protect the segments,
and apply GNU RELRO protection if needed.
- just before calling the destructors, undo the GNU RELRO
protection.
Change-Id: I50e709f03958204b8d6140c0f51ebe24fe089a1b
This moves the code that determines where the .dynamic and .ARM.exidx
sections are to a single place in soinfo_link_image().
Change-Id: I98adcb440577bed86442349f03f3c629c945efec
This patch changes the definition of the 'load_offset' field
in struct soinfo. The field is renamed because it is not the
basic load bias to add to every p_vaddr value read from the ELF
file to get the corresponding memory address.
This also slightly simplifies the relocation code.
+ Fix for proper load_bias computation for relocatable executables.
Change-Id: I72502c75a70751cba324deee7d313ae61f96609e
This patch changes the load_library() function in the
dynamic linker to avoid reserving a huge read-only
address-space range just to read the ELF header and
program header (which are typically very small and easily
fit in the first page).
Instead, we use the functions in linker_phdr.c to only
load the data that we need in a temporary mmap-allocated
page of memory, which we release when the function exits.
This avoids issues when loading very large libraries, or
simply debug versions that only need to load a tiny percentage
of their overall file content in RAM.
Change-Id: Id3a189fad2119a870a1b3d43dd81380c54ea6044
This patch introduces two new source files containing a set of functions
to manage the program header table in an ELF binary, including the ability
to load PT_LOAD segments, and apply PT_GNU_RELRO protection.
Note: the files are not used currently, this will appear in a series
of future patches that will gradually modify linker.c to use
the phdr_table_xxx functions properly.
Change-Id: Ia3d4c1ff5fc3e265d8258b64b492f4e643f51bdc
With -fstack-protector, x86 -m32 needs __stack_chk_fail_local
defined in crtbegin_*.o.
Include __stack_chk_fail_local.S in begin.S otherwise linker
(which is built w/o crt*) may not link.
Change-Id: Id242fcf3eff157264afe3b04f27288ab7991220a
This patch adds a trivial implementation of snprintf() that calls
our internal vsnprintf().
Inspection of the generated machine code showed that the linker
contained a full implementation of stdio's vfprintf. It was pulled
in because the pthread implementation uses snprintf() somewhere.
ProTip: It's possible to see why specific objects files are included
in a final binary by adding the following to your Android.mk, then
looking at the content of /tmp/MAP.TXT:
LOCAL_LDFLAGS += -Wl,-Map=/tmp/MAP.TXT
Change-Id: I325e71b0cad1d01116a2e00c09e30a80cb716aa3
This patch adds to make the linker a little bit easier to understand
by making all functions that acts on a sofino object with a soinfo_
prefix.
This is to more easily distinguish functions that operate on global
state, and those that operate on individual libraries.
This should be purely stylistic, i.e. no feature/behaviour change.
Change-Id: Ie510d13d743aa4317644caefa9910b8af7e84f44
Before changing mmap() permission to PROT_NONE in alloc_mem_region(),
such libraries once worked with a bug that uses mmap'ed region outside of
memory region allocated by alloc_mem_region(). This possibly incurs
SIGSEGV because it can overwrite memory region of previously loaded
library, but it sometimes worked, depending on loading order.
After PROT_NONE, this caused SIGSEGV earlier during calculation of
si->phdr in load_library(), but this was fixed by:
75917c84d1 Use mmap to read an ...
Now the behaviour is the same as before applying PROT_NONE in
alloc_mem_region().
This CL fixed the original issue, supporting shared libraries that have
non-zero p_vaddr in first (= with lowest p_vaddr) PT_LOAD segment.
Bug: 6561258
Change-Id: Ib6176dd3e44c4d99a340eb1cbd16fb037586b0bc
Also, fixes SIGSEV during calculation of si->phdr in load_library(),
which is caused by accessing PHDR area, which is not guaranteed to be
loaded.
Note that this usually does not happen because program header area is
covered by immediately following PT_LOAD entry. But it does not hold
always.
Bug: 6561258
Change-Id: Ie376253c773b5420279ca89044e81b1aad5a5736
Previously, the linker always loaded itself into the same
location in memory, which inhibited the effectiveness of Android's
ASLR implementation. Modify the linker code so it can be relocatable
and link itself at runtime.
Change-Id: Ia80273d7a00ff648b4da545f4b69debee6343968
Use LOCAL_NO_CRT to prevent linking against crtbegin.o, rather than
messing with build rules. This also prevents linking against crtend.o,
which isn't needed for the linker.
Change-Id: I0c5b9999be7e8676560fe145c1c033ffce8db4d1
The computation of si->base assumed that the first entry in the
program header table is a PT_PHDR. This results in the dynamic
linker crashing with a SIGSEGV/MAPERR when trying to load some
of the NDK unit test programs, which happen to have an EXIDX
header first, followed byu a PHDR one.
This patch fixes the computation by parsing the program header
table, looking explicitely for the PHDR entry. This fixes the
load of the NDK unit test programs, and doesn't affect system
libraries.
Change-Id: Id18ea6037dbe950b5abbbce816c2960321f0b81d
Modify the dynamic linker so that executables can be loaded
at locations other than 0x00000000.
Modify crtbegin* so that non-PIC compilant "thumb interwork
veneers" are not created by the linker.
Bug: 5323301
Change-Id: Iece0272e2b708c79034f302c20160e1fe9029588
The ARM static linker wasn't properly handling __exidx_start
and __exidx_end symbols. Now that the static linker has been fixed,
we don't need the dynamic linker to work around this problem.
Change-Id: I041b94903609fafab33663a7d441a5e70b7ffcdd
Since e19d702b8e, dlsym and friends use recursive mutexes that
require the current thread id, which is not available before the libc
constructor. This prevents us from using dlsym() in .preinit_array.
This change moves TLS initialization from libc constructor to the earliest
possible point - immediately after linker itself is relocated. As a result,
pthread_internal_t for the initial thread is available from the start.
As a bonus, values stored in TLS in .preinit_array are not lost when libc is
initialized.
Change-Id: Iee5a710ee000173bff63e924adeb4a4c600c1e2d
This reverts commit 61ff83475c.
This code is harmless, and only applies to the linker, so
there's no harm in keeping it in the tree a little bit longer.
Let's roll this back while we try to figure out the root cause
of bug 6314858.
Bug: 6314858
Change-Id: I9f5ed81d23a7abe273baf792aa8a0a2839ef094c
The ARM static linker wasn't properly handling __exidx_start
and __exidx_end symbols. Now that the static linker has been fixed,
we don't need the dynamic linker to work around this problem.
Change-Id: Ic567122b6c7746cc016795e2befba2c6bd7c0478
Compile the linker with -fvisibility=hidden. This reduces the number
of symbols that show up in the .dynsym section of the linker.
These symbols are never exported to other applications.
In particular, this fixes a problem with setting -DLINKER_DEBUG=1
introduced in 468319ce4f.
Because the symbols "debug_verbosity" and "format_log" have not been
resolved before the linker links itself, any attempt to call
PRINT / INFO / TRACE / WARN / ERROR will result in a segfault.
This change allows the static linker to produce a relative reference
to these symbols rather than relying on relocation.
This also has a nice side effect of making the linker slightly smaller
and slightly more optimized.
The following symbols no longer in the .dynsym section of the linker
after this change:
-addr_to_name
-call_constructors_recursi
-calloc
-debugger_init
-debugger_signal_handler
-debug_verbosity
-dladdr
-dlclose
-dlerror
-dl_lock
-dlopen
-dlsym
-dl_unwind_find_exidx
-find_containing_library
-find_containing_symbol
-find_library
-format_buffer
-free
-libdl_info
-linker_env_get
-linker_env_init
-linker_env_secure
-linker_env_unset
-linker_get_error
-__linker_init
-lookup
-lookup_in_library
-malloc
-notify_gdb_of_libraries
-notify_gdb_of_load
-notify_gdb_of_unload
-realloc
-rtld_db_dlactivity
-unload_library
-vsnprintf
Bug: 5827809
Change-Id: I5e8cd7dcf48c1d6831a970a67f63f24916c5e437
When the dynamic linker loads a shared library into memory, it
initially allocates a chunk of memory. The memory is then carved
into smaller chunks for each LOAD region, and appropriate memory
protections applied.
Modify the initial memory allocation so that the pages are mapped
as PROT_NONE, rather than PROT_READ / PROT_EXEC. This ensures that
gaps between LOAD regions are not inadvertantly readable / executable.
(Long term, we should munmap() these gaps entirely)
Change-Id: If128a203ccc6fe12dcbbd2bfe0cf13a2045675af
If we catch a fatal signal that won't automatically re-throw when
the thread resumes, re-throw it manually. (Common examples are
SIGPIPE and the SIGFPE from integer division by zero.)
Change-Id: I329e6d4db907047c555957b42cbd09c50fc808e7
This adds the thread id and name to the "Fatal signal" logging,
making it easier to track down where in process it actually crashed.
Change-Id: I17a365042b2f10b161debe98bc2e7070af055dfb
Add support for PT_GNU_RELRO. This allows the static linker to
indicate that certain regions of memory should be marked as
"read-only" after dynamic linking is complete.
See:
* http://www.akkadia.org/drepper/nonselsec.pdf (section 6)
* http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html
Note that this change has no effect on Android right now, because
we don't compile our code with relro enabled.
Change-Id: I6541f8775367e8558b4388f7d105b1ae6e8f046b
That is to fix the bug:
dlxxx functions can't be called recursively.
For example, if we use dlopen() to use open one library whose constructor
also calls dlopen() in order to open another library, then the thread is
dead-blocked.
By changing the dl_lock from a non-recursive lock to a recursive lock, we can
prevent the thread from dead-blocked by recursive dlxxx calls in the same
thread context.
Change-Id: I1018b41c82f4641cc009c0a2eda31f5a47a534f9
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
