I gave up trying to use the usual thread-local buffer idiom; calls to
calloc(3) and free(3) from any of the "dl" functions -- which live in
the dynamic linker -- end up resolving to the dynamic linker's stubs.
I tried to work around that, but was just making things more complicated.
This alternative costs us a well-known TLS slot (instead of the
dynamically-allocated TLS slot we'd have used otherwise, so no difference
there), plus an extra buffer inside every pthread_internal_t.
Bug: 5404023
Change-Id: Ie9614edd05b6d1eeaf7bf9172792d616c6361767
Add unit tests for dlerror(3) in various situations. I think We're at least
as good as glibc now.
Also factor out the ScopedPthreadMutexLock and use it here too.
Bug: http://code.google.com/p/android/issues/detail?id=38398
Change-Id: I040938b4366ab836e3df46d1d8055b92f4ea6ed8
To properly support legacy ARM shared libraries, libc.so needs
to export the symbols __dso_handle and atexit, even though
these are now supplied by the crt startup code.
This patch reshuffles the existing CRT_LEGACY_WORKAROUND
conditionally compiled code slightly so it works as the
original author likely intended.
Change-Id: Id6c0e94dc65b7928324a5f0bad7eba6eb2f464b9
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@gmail.com>
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
In particular this affects assert(3) and __cxa_pure_virtual, both of
which have managed to confuse people this week by apparently aborting
without reason. (Because stderr goes nowhere, normally.)
Bug: 6852995
Bug: 6840813
Change-Id: I7f5d17d5ddda439e217b7932096702dc013b9142
I've basically just copied the relevant bits out of liblog and
EventLog.cpp. While this will let us do the uid logging we want
to address the concerns in 245c07027f78565858dd489eb0d94c3d48743e9d
it doesn't give us much else.
Change-Id: Icac6ff20bc0a3ade5927f6f76fedffe1ae6f8522
Rewrite
crtbegin.S -> crtbegin.c
crtbegin_so.S -> crtbegin_so.c
This change allows us to generate PIC code without relying
on text relocations.
As a consequence of this rewrite, also rewrite
__dso_handle.S -> __dso_handle.c
__dso_handle_so.S -> __dso_handle_so.c
atexit.S -> atexit.c
In crtbegin.c _start, place the __PREINIT_ARRAY__, __INIT_ARRAY__,
__FINI_ARRAY__, and __CTOR_LIST__ variables onto the stack, instead of
passing a pointer to the text section of the binary.
This change appears sorta wonky, as I attempted to preserve,
as much as possible, the structure of the original assembly.
As a result, you have C files including other C files, and other
programming uglyness.
Result: This change reduces the number of files with text-relocations
from 315 to 19 on my Android build.
Before:
$ scanelf -aR $OUT/system | grep TEXTREL | wc -l
315
After:
$ scanelf -aR $OUT/system | grep TEXTREL | wc -l
19
Change-Id: Ib9f98107c0eeabcb606e1ddc7ed7fc4eba01c9c4
If two or more rapid dns requests for the same server are done
from different threads it turns into separate dns reques, if
the response of the request isn't found in the cache.
This patch avoid multiple request for the same server by
letting subsequents request wait until the first request
has finished.
Change-Id: Ic72ea0e7d3964a4164eddf866feb4357ec4dfe54
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
First commit:
Revert "Revert "am be741d47: am 2f460fbe: am 73b5cad9: Merge "bionic: Fix wrong kernel_id in pthread descriptor after fork()"""
This reverts commit 06823da2f0.
Second commit:
bionic: fix atfork hanlder_mutex deadlock
This cherry-picks commit 34e89c232d
After applying the kernel_id fix, the system refused to boot up and we
got following crash log:
I/DEBUG ( 113): pid: 618, tid: 618 >>> org.simalliance.openmobileapi.service:remote <<<
I/DEBUG ( 113): signal 16 (SIGSTKFLT), code -6 (?), fault addr --------
I/DEBUG ( 113): eax fffffe00 ebx b77de994 ecx 00000080 edx 00724002
I/DEBUG ( 113): esi 00000000 edi 00004000
I/DEBUG ( 113): xcs 00000073 xds 0000007b xes 0000007b xfs 00000000 xss 0000007b
I/DEBUG ( 113): eip b7761351 ebp bfdf3de8 esp bfdf3dc4 flags 00000202
I/DEBUG ( 113): #00 eip: 00015351 /system/lib/libc.so
I/DEBUG ( 113): #01 eip: 0000d13c /system/lib/libc.so (pthread_mutex_lock)
I/DEBUG ( 113): #02 eip: 00077b48 /system/lib/libc.so (__bionic_atfork_run_prepare)
I/DEBUG ( 113): #03 eip: 00052cdb /system/lib/libc.so (fork)
I/DEBUG ( 113): #04 eip: 0009ae91 /system/lib/libdvm.so (_Z18dvmOptimizeDexFileillPKcjjb)
I/DEBUG ( 113): #05 eip: 000819d6 /system/lib/libdvm.so (_Z14dvmJarFileOpenPKcS0_PP7JarFileb)
I/DEBUG ( 113): #06 eip: 000b175e /system/lib/libdvm.so (_ZL40Dalvik_dalvik_system_DexFile_openDexFilePKjP6JValue)
I/DEBUG ( 113): #07 eip: 0011fb94 /system/lib/libdvm.so
Root cause:
The atfork uses the mutex handler_mutex to protect the atfork_head. The
parent will call __bionic_atfork_run_prepare() to lock the handler_mutex,
and need both the parent and child to unlock their own copy of handler_mutex
after fork. At that time, the owner of hanlder_mutex is set as the parent.
If we apply the kernel_id fix, then the child's kernel_id will be set as
child's tid.
The handler_mutex is a recursive lock, and pthread_mutex_unlock(&hander_mutex)
will fail because the mutex owner is the parent, while the current tid
(__get_thread()->kernel_id) is child, not matched with the mutex owner.
At that time, the handler_mutex is left in lock state.If the child wants to
fork other process after than, then it will try to lock handler_mutex, and
then be deadlocked.
Fix:
Since the child has its own copy of vm space from the the parent, the
child space's handler_mutex should be reset to the initialized state.
Change-Id: I3907dd9a153418fb78862f2aa6d0302c375d9e27
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Change-Id: Ic8072f366a877443a60fe215f3c00b3df5a259c8
After forking, the kernel_id field in the phtread_internal_t returned by pthread_self()
is incorrect --- it's the tid from the parent, not the new tid of the
child.
The root cause is that: currently the kernel_id is set by
_init_thread(), which is called in 2 cases:
(1) called by __libc_init_common(). That happens when the execv( ) is
called after fork( ). But when the zygote tries to fork the android
application, the child application doesn't call execv( ), instread, it
tries to call the Java main method directly.
(2) called by pthread_create(). That happens when a new thread is
created.
For the lead thread which is the thread created by fork(), it should
call execv() but it doesn't, as described in (1) above. So its kernel_id
will inherit the parent's kernel_id.
Fixed it in this patch.
Change-Id: I63513e82af40ec5fe51fbb69456b1843e4bc0fc7
Signed-off-by: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
This patch is the first in a series that aims at cleaning up the
public C library headers (which end up being distributed with the NDK).
<resolv.h> and <time.h> contain declarations that should not be public.
They are used by other parts of the platform, but NDK applications should
not use or rely on them.
So copy them to private <bionic_time.h> and <resolv_iface.h> headers
and use a guard macro to avoid conflicts when both headers are included
at the same time.
The idea is that we're going to fix the other platform modules to
include these private headers. After this is done, we will remove the
duplicate definitions from <resolv.h> and <time.h>
Change-Id: I121c11936951c98ca7165e811126ed8a4a3a394d
We're going to modify the __atomic_xxx implementation to provide
full memory barriers, to avoid problems for NDK machine code that
link to these functions.
First step is to remove their usage from our platform code.
We now use inlined versions of the same functions for a slight
performance boost.
+ remove obsolete atomics_x86.c (was never compiled)
NOTE: This improvement was benchmarked on various devices.
Comparing a pthread mutex lock + atomic increment + unlock
we get:
- ARMv7 emulator, running on a 2.4 GHz Xeon:
before: 396 ns after: 288 ns
- x86 emulator in KVM mode on same machine:
before: 27 ns after: 27 ns
- Google Nexus S, in ARMv7 mode (single-core):
before: 82 ns after: 76 ns
- Motorola Xoom, in ARMv7 mode (multi-core):
before: 121 ns after: 120 ns
The code has also been rebuilt in ARMv5TE mode for correctness.
Change-Id: Ic1dc72b173d59b2e7af901dd70d6a72fb2f64b17
Our dlmalloc implementation currently calls abort() when it detects
that the heap is corrupted, or that an invalid pointer is passed to
one of its functions.
The only way to detect this is because abort() will force-fully
crash the current program with a magic fault address of '0xdeadbaad'.
However, this is not really well documented, and a frequent topic
on the android-ndk forum (among others).
This change makes our dlmalloc code dump a simple message to the
log just before the abort() call (and hence before the stack trace)
to better help identify the problem.
Change-Id: Iebf7eb7fe26463ecadfaca8f247d237edb441e3c
Unfortunately, legacy .so files for ARM don't have a correct crtbegin file.
Consequently, we have to grandfather the old __dso_handle behaviour.
Add some ifdefs for ARM to allow it to use the old code until we can work
out a transition.
Change-Id: I6a28f368267d792c94e1d985d8344023bc632f6f
Author: H.J. Lu <hongjiu.lu@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Initial commit for dns cache per interface.
Added a type that holds a reference to a
cache and name of associated interface,
address of interface, name server(s)
associated with an interface etc.
New functions to set default interface,
address of name servers etc.
Change-Id: Ie991bc5592fd998409853d8bf77d7fe69035dac5
Several updates to Bionic crt*.o files to implement Linux/x86
stack unwind/exception handling.
Mark __dso_handle as hidden.
Note: Requires complete rebuild due to CRT changes. Google will
need to regenerate and check-in all the prebuilt x86 CRT object
files and libraries which link to them.
Change-Id: I191ce1afb0dee7bbc28dcd9694e5919226dbd070
Signed-off-by: Bruce J Beare <bruce.j.beare@intel.com>
Signed-off-by: Mark D Horn <mark.d.horn@intel.com>
Author: Lu, Hongjiu <hongjiu.lu@intel.com>
Also add missing declarations to misc. functions.
Fix clearerr() implementation (previous was broken).
Handle feature test macros like _POSIX_C_SOURCE properly.
Change-Id: Icdc973a6b9d550a166fc2545f727ea837fe800c4
With this patch, _and_ an upcoming build/ patch, the destruction
of static C++ objects contained in shared libraries will happen
properly when dlclose() is called.
Note that this change introduces crtbegin_so.S and crtend_so.S which
are currently ignored by the build system.
+ move definition of __dso_handle to the right place
(before that, all shared libraries used the __dso_handle
global variable from the C library).
Note that we keep a 'weak' __dso_handle in aeabi.c to avoid
breaking the build until the next patch to build/core/combo/
appears. We will be able to remove that later.
+ move bionic/aeabi.c to arch-arm/bionic/ (its proper location)
Change-Id: Ie771aa204e3acbdf02fd30ebd4150373a1398f39
NOTE: The NDK will need to be modified to enable this feature in
the shared libraries that are generated through it.
We simply copy the stuff we need from cutils headers.
A future patch will change cutils to include the private <bionic_atomic_inline.h>
Change-Id: Ib6fd9a03bc9e337ce867bd606dc94c2b4438480a
The problem was that the 'defdname' field of res_state structure
was not properly initialized in __res_vinit(). This field is used
to store the default domain name, which is normally build from
calling gethostname() (see line 549 of res_init.c).
Unfortunately, in the typical Android case, gethostname() returns
an error (the hostname is configured) and a random stack string is
used later to build the DNS search list (see lines 556+ in res_init.c)
For the sake of illustration, let's say the search list is set to
a random value like 'xWLK'.
The end result is that when trying to result an unknown domain name
(e.g. 'www.ptn'), the query fails then the resolver tries to make a
new query with the DNS search list path(s) appended (e.g. 'www.ptn.xWLK').
The patch simply initializes 'defdname' to an empty string to avoid
this when the net.dns.search system property is not set.
Also contains whitespace/formatting fixes
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 TLS access functions to use the kernel helper.
This Fix is verified on ST Ericsson's U8500 platform and Submitted on behalf of a third-party:
Surinder-pal SINGH from STMicroelectronics.
This is needed to properly initialize the C runtime when libc.so
is loaded by the dynamic linker.
Move the temporary TLS setup before the first system call, just
in case something really horrible happens, we won't crash when
trying to write an error code in 'errno'
Remove the broken TLS_SLOT_THREAD_ID setup. First, this slot
should normally receive the address of a pthread_internal_t,
not a kernel thread identifier. Second, it is never used by
the linker anyway.
Also remove an obsolete comment.
Simplify the code a little, removing un-necessary mutex locks/unlocks.
Provide slightly better diagnostic message in case of corruption.
Use snprintf/strlcat instead of sprintf/strcat
The problem was due to the fact that, in the case of dynamic executables,
the dynamic linker calls the DT_PREINIT_ARRAY, DT_INIT and DT_INIT_ARRAY
constructors when loading shared libraries and dynamic executables,
*before* calling the executable's entry point (i.e. arch-$ARCH/bionic/crtbegin_dynamic.c)
which in turns call __libc_init() in libc.so, as defined by bionic/libc_init_dynamic.c
The latter did call these constructors array again, mistakenly.
The patch also updates the documentation of many related functions.
Also adds a new section to linker/README.TXT explaining restrictions on
C library usage.
The patch has been tested on a Dream for stability issues with
proprietary blobs:
- H264 decoding works
- Camera + Video recording works
- GPS works
- Sensors work
The tests in system/extra/tests/bionic/libc/common/test_static_cpp_mutex.cpp has been
run and shows the static C++ constructor being called only once.
