Linker is now able to resolve symlinked libraries correctly.
soinfo is extended to save the graph of dependencies during
load/unload. Dependencies are used only in CallConstructor.
Bug: 9741592
Change-Id: Id9c48a74c46aa89bcdf3d54ec2f8ba3d398130b1
Freeing block mprotects on the page which it turn
may lead to application crash if linker subsequently
tries to modify another block on the page.
Bug: 14895266
Change-Id: I8ff7f5df467d7be184242de652032b3c84e24b76
Don't support the dynamic linker loading ET_EXEC executables. Only
support ET_DYN executables.
Bug: 14566672
Change-Id: Ia1f2bfffe7ea867c1cd62e67d7fd637c60c0728d
If the file has no relro segment, the generated relro file will have
length 0, which caused mmap to fail. If the relro file has nonzero size,
but is too short (e.g. because it's for the wrong version of the
library), the linker would segfault while comparing the data. Fix both
these issues: don't try to map a zero length file, and don't try to
compare data that would be beyond the end of the file.
Improve test to explicitly generate two versions of the library: one
with -z relro, and one with -z norelro, so we can test both cases; also
explicitly test the case where the relro file has length 0.
Bug: 14299541
Change-Id: Id8b95585edda90e8bb5de452a35b70ed2d224934
Because we re-raise various signals, we corrupt the si_code that debuggerd
sees when it ptraces our siginfo. One possible solution (shown here) is to
pass the original si_code value in the message we send to debuggerd.
Change-Id: I76f9aa2c0442e5cab611d132532409e700383907
Add missing second param to soinfo_link_image in a section that's not
compiled on ARM.
Bug: 13005501
Change-Id: Id0ede8e03da4e05b25c0aeb24a840f868031d4e8
This has been annoying me for a while, because it's often quite misleading.
Today, for example, I saw:
Fatal signal 13 (SIGPIPE) at 0x6573 (code=0), thread 25971 (top)
where the apparent address is actually the pid of the signal source (in this
case the kernel on behalf of the thread itself).
This patch isn't as fancy as strace, but it at least means we never say
anything misleading. We could decode the si_code field like strace and
debuggerd, but I'm reluctant to do that without some way to share the code
between at least bionic and debuggerd.
Examples after:
Fatal signal 13 (SIGPIPE), code 0 in tid 9157 (top)
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9142 (crasher64)
Fatal signal 6 (SIGABRT), code -6 in tid 9132 (crasher64)
(Note that the code still shows as 0 for SIGPIPE in the signal handler itself
but as -6 (SI_TKILL) in debuggerd; this is actually correct --- debuggerd is
showing the re-raised signal sent at the end of the signal handler that
initially showed the correct code 0.)
Change-Id: I71cad4ab61f422a4f6687a60ac770371790278e0
Add flags and a file descriptor to android_dlopen_ext() to allow writing
the RELRO section of the loaded library to a file after relocation
processing, and to allow mapping identical pages from the file over the
top of relocated memory in another process. Explicitly comparing the
pages is required in case a page contains a reference to a symbol
defined in another library loaded at a random base address.
Bug: 13005501
Change-Id: Ibb5b2d384edfaa5acf3e97a5f8b6115c10497a1e
Add flags and parameters to android_dlopen_ext() to allow loading a
library at an already-reserved fixed address. If the library to be
loaded will not fit within the space reserved, then the linker will
either fail, or allocate its own address space as usual, according to
which flag has been specified. This behaviour only applies to the
specific library requested; any other libraries loaded as dependencies
will be loaded in the normal fashion.
There is a new gtest included to cover the functionality added.
Bug: 13005501
Change-Id: I5d1810375b20fc51ba6a9b3191a25f9792c687f1
Add a function "android_dlopen_ext()", defined in <android/dlext.h>.
This is an extended version of dlopen() which takes a struct for passing
additional parameters for Android-specific functionality. This will be
used to support RELRO section sharing between separate processes.
Bug: 13005501
Change-Id: I9c99b2f2a02ee329dedaeba09ef3a1113b17b2d6
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
Our <machine/asm.h> files were modified from upstream, to the extent
that no architecture was actually using the upstream ENTRY or END macros,
assuming that architecture even had such a macro upstream. This patch moves
everyone to the same macros, with just a few tweaks remaining in the
<machine/asm.h> files, which no one should now use directly.
I've removed most of the unused cruft from the <machine/asm.h> files, though
there's still rather a lot in the mips/mips64 ones.
Bug: 12229603
Change-Id: I2fff287dc571ac1087abe9070362fb9420d85d6d
When bionic's dynamic linker processes the .dynamic section of a MIPS ELF binary and encounters the DT_MIPS_RLD_MAP dynamic array tag, it calculates the address of where to write a pointer to the _r_debug structure. The current implementation simply reads the value given in the d_ptr field and writes the pointer address to that location. However, this value has to be adjusted to reflect the real load address of the binary. Otherwise the linker will write to a faulty location possibly resulting in a crash when linking a MIPS binary that includes DT_MIPS_RLD_MAP. This change corrects that problem.
Change-Id: I1a91874f7ab47289001fe72d9016660c14c70362
Signed-off-by: Benjamin Adolphi <b.adolphi@gmail.com>
Remove the linker's reliance on BSD cruft and use the glibc-style
ElfW macro. (Other code too, but the linker contains the majority
of the code that needs to work for Elf32 and Elf64.)
All platforms need dl_iterate_phdr_static, so it doesn't make sense
to have that part of the per-architecture configuration.
Bug: 12476126
Change-Id: I1d7f918f1303a392794a6cd8b3512ff56bd6e487
Also move some of the stuff that should be in <link.h> out of the
private "linker.h", to make it clearer that these are public API
known to gdb that we can't change.
Bug: 12554197
Change-Id: I830e1260d3d8b833ed99bc1518f1c6b6102be8af
Some system functions like munmap expect soinfo's size to be size_t, but currently
it is unsigned. Change it to size_t to fit 64bit's portability.
Change-Id: I0bf6d522b38b0cd9bf1db05b004b5326217412a2
Signed-off-by: Weiwu Chen <weiwu.chen@intel.com>
Signed-off-by: Qiming Shi <qiming.shi@intel.com>
Do not use the magic number 0xFFFFFFFFU to represent the max value of an address
as it's not correct on 64bit platform. We should use UINTPTR_MAX instead.
Change-Id: I1fc6f5864a651b2eddea2333cb0788f9d9223270
Signed-off-by: Qiming Shi <qiming.shi@intel.com>
Signed-off-by: Weiwu Chen <weiwu.chen@intel.com>
We're not going to have init(1) set LD_LIBRARY_PATH globally on 64-bit.
This patch makes it possible for libnativehelper to set LD_LIBRARY_PATH
in each Java VM (to support System.loadLibrary) without also hard-coding
the default search path there.
Change-Id: If13961fae976e06dd80d5ef522f31e8b7eb01154
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
