the issue here is that abort() can be called from anywhere, in particular
from malloc or free. When we try to use the debug_log functions, these
can end up calling into some code (like malloc/free) that called abort()
in the first place and end up in an infinite recursion loop.
Do not submit this patch before the one that modifies the Android emulator to
work-around a weird ARMv7 emulation issue. This is done to temporarily re-allow
the -user builds needed for QA.
This is required to work-around some corny bugs in ARMv7 emulation.
The emulation itself is required to run the dex pre-optimization pass
for -user builds.
* changes:
bionic/linker: allow resolving of symbols from library back to executable
bionic/linker: change lookup() to return soinfo, not base
Revert "Revert "bionic/linker: fix symbol lookup during relocations""
372 MB/s for large transfers, 440 MB/s for smaller ones down to 1KB. 130 MB/s for very small transfers ( < 32 bytes )
Performance is similar with non-congruent buffers.
When resolving relocations while loading a library, the linker used to find
symbols by looking them up in the list of all linked libraries for the current
process, as opposed to following just the library's DT_NEEDED entries. This
can cause a problem where the symbol is picked up from the wrong library.
Signed-off-by: Iliyan Malchev <malchev@google.com>
This is used to perform a mutex lock for a given amount of
milliseconds before giving up. Using the _np prefix since this
is absolutely not portable.
Also remove a compiler warning in pthread_attr_getstackaddr
For performance reasons, we don't call the kernel helper. Instead, we directly
access the TLS register on ARMv6 and higher. For ARMv5TE, keep using the hard-coded
address populated by the kernel on each task switch.
NOTE: Since we don't call the kernel helper, this must precisely match your
kernel configuration. This is controlled by setting the ARCH_ARM_HAVE_TLS_REGISTER
variable to 'true' in your board configuration file.
The problem is that time_t is signed, and the original code relied on the
fact that (X + c < X) in case of overflow for c >= 0. Unfortunately, this
condition is only guaranteed by the standard for unsigned arithmetic, and
the gcc 4.4.0 optimizer did completely remove the corresponding test from
the code. This resulted in a missing boundary check, and an infinite loop.
The problem is solved by testing explicitely for TIME_T_MIN and TIME_T_MAX
in the loop that uses this.
Also fix increment_overflow and long_increment_overflow which were buggy
for exactly the same reasons.
Note: a similar fix is needed for system/core/libcutils
Merge commit 'fde8642fc43bdd224e43e5ee9583a49a758fb03c'
* commit 'fde8642fc43bdd224e43e5ee9583a49a758fb03c':
bionic/linker: keep track of opened libraries by basename
Merge commit '22b5eb858dcbb537f2522ad920ca793348d574a2'
* commit '22b5eb858dcbb537f2522ad920ca793348d574a2':
linker: remove newlines from DL_ERR so that dlerror works correctly
Prior to this change, the dynamic loader kept track of opened libraries
either by their base name (i.e., libfoo.so instead of /system/lib/libfoo.so)
when the shared library was loaded through the DT_NEEDED tag in an ELF header,
or by whatever name was passed to dlopen(). This created a number of problems,
among which:
1. dlopen("libfoo.so") and dlopen("/path/to/libfoo.so") would open the same
library twice;
2. dlopen("/path/to/libfoo.so") and then dlopen("libbar.so"), where libbar.so
depends on libfoo.so, would open libfoo.so twice.
This patch makes the dynamic loader keep track of each loaded library by
basename, which resolves the above ambiguity. The patch also enforces
library lookup by base name, which means that it will refuse to load another
library that has the same name.
Thanks for the inspiration Iliyan.
Signed-off-by: Erik Gilling <konkers@android.com>
Cc: Iliyan Malchev <malchev@google.com>
Merge commit '3773d35eb98e22b5edab4d82fb72bdf86ff80494'
* commit '3773d35eb98e22b5edab4d82fb72bdf86ff80494':
Make the DNS resolver accept domain names with an underscore.
More precisely, this accepts domain labels with an underscore in
the middle (i.e. not at the start or the end of the label). This
is needed to perform complex CNAME chain resolution in certain
VPN networks.
