Regenerate NOTICE files.
Also clean up some obsolete cruft. Change-Id: Iec3b36f6607f7a08b72de99294ed5b6cd910dd5f
This commit is contained in:
parent
c9f8081425
commit
0493a6f7be
15
ABI-bugs.txt
Normal file
15
ABI-bugs.txt
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
KNOWN ABI BUGS
|
||||||
|
--------------
|
||||||
|
|
||||||
|
time_t is 32-bit. http://b/5819737
|
||||||
|
|
||||||
|
off_t is 32-bit. There is off64_t, but no _FILE_OFFSET_BITS support.
|
||||||
|
|
||||||
|
sigset_t is too small on ARM and x86 (but correct on MIPS), so support
|
||||||
|
for real-time signals is broken. http://b/5828899
|
||||||
|
|
||||||
|
Too few TLS slots mean we can't allocate 128 pthread_key_t instances,
|
||||||
|
which POSIX says should be the minimum.
|
||||||
|
|
||||||
|
atexit(3) handlers registered by a shared library aren't called on
|
||||||
|
dlclose(3); this only affects ARM. http://b/4998315
|
28
libc/NOTICE
28
libc/NOTICE
@ -4030,6 +4030,34 @@ SUCH DAMAGE.
|
|||||||
|
|
||||||
-------------------------------------------------------------------
|
-------------------------------------------------------------------
|
||||||
|
|
||||||
|
Copyright (c) 2013 ARM Ltd
|
||||||
|
All rights reserved.
|
||||||
|
|
||||||
|
Redistribution and use in source and binary forms, with or without
|
||||||
|
modification, are permitted provided that the following conditions
|
||||||
|
are met:
|
||||||
|
1. Redistributions of source code must retain the above copyright
|
||||||
|
notice, this list of conditions and the following disclaimer.
|
||||||
|
2. Redistributions in binary form must reproduce the above copyright
|
||||||
|
notice, this list of conditions and the following disclaimer in the
|
||||||
|
documentation and/or other materials provided with the distribution.
|
||||||
|
3. The name of the company may not be used to endorse or promote
|
||||||
|
products derived from this software without specific prior written
|
||||||
|
permission.
|
||||||
|
|
||||||
|
THIS SOFTWARE IS PROVIDED BY ARM LTD ``AS IS'' AND ANY EXPRESS OR IMPLIED
|
||||||
|
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||||
|
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
||||||
|
IN NO EVENT SHALL ARM LTD BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
||||||
|
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
|
||||||
|
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
|
||||||
|
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
|
||||||
|
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
|
||||||
|
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
|
||||||
|
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------
|
||||||
|
|
||||||
Copyright (c)1999 Citrus Project,
|
Copyright (c)1999 Citrus Project,
|
||||||
All rights reserved.
|
All rights reserved.
|
||||||
|
|
||||||
|
54
libc/README
54
libc/README
@ -1,54 +0,0 @@
|
|||||||
Welcome to Bionic, Android's small and custom C library for the Android
|
|
||||||
platform.
|
|
||||||
|
|
||||||
Bionic is mainly a port of the BSD C library to our Linux kernel with the
|
|
||||||
following additions/changes:
|
|
||||||
|
|
||||||
- no support for locales
|
|
||||||
- no support for wide chars (i.e. multi-byte characters)
|
|
||||||
- its own smallish implementation of pthreads based on Linux futexes
|
|
||||||
- support for x86, ARM and ARM thumb CPU instruction sets and kernel interfaces
|
|
||||||
|
|
||||||
Bionic is released under the standard 3-clause BSD License
|
|
||||||
|
|
||||||
Bionic doesn't want to implement all features of a traditional C library, we only
|
|
||||||
add features to it as we need them, and we try to keep things as simple and small
|
|
||||||
as possible. Our goal is not to support scaling to thousands of concurrent threads
|
|
||||||
on multi-processors machines; we're running this on cell-phones, damnit !!
|
|
||||||
|
|
||||||
Note that Bionic doesn't provide a libthread_db or a libm implementation.
|
|
||||||
|
|
||||||
|
|
||||||
Adding new syscalls:
|
|
||||||
====================
|
|
||||||
|
|
||||||
Bionic provides the gensyscalls.py Python script to automatically generate syscall
|
|
||||||
stubs from the list defined in the file SYSCALLS.TXT. You can thus add a new syscall
|
|
||||||
by doing the following:
|
|
||||||
|
|
||||||
- edit SYSCALLS.TXT
|
|
||||||
- add a new line describing your syscall, it should look like:
|
|
||||||
|
|
||||||
return_type syscall_name(parameters) syscall_number
|
|
||||||
|
|
||||||
- in the event where you want to differentiate the syscall function from its entry name,
|
|
||||||
use the alternate:
|
|
||||||
|
|
||||||
return_type funcname:syscall_name(parameters) syscall_number
|
|
||||||
|
|
||||||
- additionally, if the syscall number is different between ARM and x86, use:
|
|
||||||
|
|
||||||
return_type funcname[:syscall_name](parameters) arm_number,x86_number
|
|
||||||
|
|
||||||
- a syscall number can be -1 to indicate that the syscall is not implemented on
|
|
||||||
a given platform, for example:
|
|
||||||
|
|
||||||
void __set_tls(void*) arm_number,-1
|
|
||||||
|
|
||||||
|
|
||||||
the comments in SYSCALLS.TXT contain more information about the line format
|
|
||||||
|
|
||||||
You can also use the 'checksyscalls.py' script to check that all the syscall
|
|
||||||
numbers you entered are correct. It does so by looking at the values defined in
|
|
||||||
your Linux kernel headers. The script indicates where the values are incorrect
|
|
||||||
and what is expected instead.
|
|
@ -25,7 +25,10 @@
|
|||||||
# - additionally, if the syscall number is different amoung ARM, and x86, MIPS use:
|
# - additionally, if the syscall number is different amoung ARM, and x86, MIPS use:
|
||||||
# return_type funcname[:syscall_name](parameters) arm_number,x86_number,mips_number
|
# return_type funcname[:syscall_name](parameters) arm_number,x86_number,mips_number
|
||||||
#
|
#
|
||||||
# the file is processed by a python script named gensyscalls.py
|
# This file is processed by a python script named gensyscalls.py.
|
||||||
|
#
|
||||||
|
# The checksyscalls.py script can check that the syscall numbers here are
|
||||||
|
# correct by comparing them to the numbers in the Linux kernel headers.
|
||||||
#
|
#
|
||||||
|
|
||||||
# process management
|
# process management
|
||||||
|
@ -1,400 +0,0 @@
|
|||||||
Bionic C Library Overview:
|
|
||||||
==========================
|
|
||||||
|
|
||||||
Introduction:
|
|
||||||
|
|
||||||
Core Philosophy:
|
|
||||||
|
|
||||||
The core idea behind Bionic's design is: KEEP IT REALLY SIMPLE.
|
|
||||||
|
|
||||||
This implies that the C library should only provide lightweight wrappers
|
|
||||||
around kernel facilities and not try to be too smart to deal with edge cases.
|
|
||||||
|
|
||||||
The name "Bionic" comes from the fact that it is part-BSD and part-Linux:
|
|
||||||
its source code consists in a mix of BSD C library pieces with custom
|
|
||||||
Linux-specific bits used to deal with threads, processes, signals and a few
|
|
||||||
others things.
|
|
||||||
|
|
||||||
All original BSD pieces carry the BSD copyright disclaimer. Bionic-specific
|
|
||||||
bits carry the Android Open Source Project copyright disclaimer. And
|
|
||||||
everything is released under the BSD license.
|
|
||||||
|
|
||||||
Architectures:
|
|
||||||
|
|
||||||
Bionic currently supports the ARM and x86 instruction sets. In theory, it
|
|
||||||
should be possible to support more, but this may require a little work (e.g.
|
|
||||||
adding system call IDs to SYSCALLS.TXT, described below, or modifying the
|
|
||||||
dynamic linker).
|
|
||||||
|
|
||||||
The ARM-specific code is under arch-arm/ and the x86-specific one is under
|
|
||||||
arch-x86/
|
|
||||||
|
|
||||||
Note that the x86 version is only meant to run on an x86 Android device. We
|
|
||||||
make absolutely no claim that you could build and use Bionic on a stock x86
|
|
||||||
Linux distribution (though that would be cool, so patches are welcomed :-))
|
|
||||||
|
|
||||||
Syscall stubs:
|
|
||||||
|
|
||||||
Each system call function is implemented by a tiny assembler source fragment
|
|
||||||
(called a "syscall stub"), which is generated automatically by
|
|
||||||
tools/gensyscalls.py which reads the SYSCALLS.TXT file for input.
|
|
||||||
|
|
||||||
SYSCALLS.TXT contains the list of all syscall stubs to generate, along with
|
|
||||||
the corresponding syscall numeric identifier (which may differ between ARM
|
|
||||||
and x86), and its signature
|
|
||||||
|
|
||||||
If you modify this file, you may want to use tools/checksyscalls.py which
|
|
||||||
checks its content against official Linux kernel header files, and will
|
|
||||||
report errors when invalid syscall ids are used.
|
|
||||||
|
|
||||||
Sometimes, the C library function is really a wrapper that calls the
|
|
||||||
corresponding syscall with another name. For example, the exit() function
|
|
||||||
is provided by the C library and calls the _exit() syscall stub.
|
|
||||||
|
|
||||||
See SYSCALLS.TXT for documentation and details.
|
|
||||||
|
|
||||||
|
|
||||||
time_t:
|
|
||||||
|
|
||||||
time_t is 32-bit as defined by the kernel on 32-bit CPUs. A 64-bit version
|
|
||||||
would be preferrable to avoid the Y2038 bug, but the kernel maintainers
|
|
||||||
consider that this is not needed at the moment.
|
|
||||||
|
|
||||||
Instead, Bionic provides a <time64.h> header that defines a time64_t type,
|
|
||||||
and related functions like mktime64(), localtime64(), etc...
|
|
||||||
|
|
||||||
strftime() uses time64_t internally, so the '%s' format (seconds since the
|
|
||||||
epoch) is supported for dates >= 2038.
|
|
||||||
|
|
||||||
|
|
||||||
strftime_tz():
|
|
||||||
|
|
||||||
Bionic also provides the non-standard strftime_tz() function, a variant
|
|
||||||
of strftime() which also accepts a time locale descriptor as defined
|
|
||||||
by "struct strftime_locale" in <time.h>.
|
|
||||||
|
|
||||||
This function is used by the low-level framework code in Android.
|
|
||||||
|
|
||||||
|
|
||||||
Timezone management:
|
|
||||||
|
|
||||||
The name of the current timezone is taken from the TZ environment variable,
|
|
||||||
if defined. Otherwise, the system property named 'persist.sys.timezone' is
|
|
||||||
checked instead.
|
|
||||||
|
|
||||||
The zoneinfo timezone database and index files are located under directory
|
|
||||||
/system/usr/share/zoneinfo, instead of the more Posix-compliant path of
|
|
||||||
/usr/share/zoneinfo
|
|
||||||
|
|
||||||
|
|
||||||
off_t:
|
|
||||||
|
|
||||||
For similar reasons, off_t is 32-bit. We define loff_t as the 64-bit variant
|
|
||||||
due to BSD inheritance, but off64_t should be available as a typedef to ease
|
|
||||||
porting of current Linux-specific code.
|
|
||||||
|
|
||||||
|
|
||||||
Linux kernel headers:
|
|
||||||
|
|
||||||
Bionic comes with its own set of "clean" Linux kernel headers to allow
|
|
||||||
user-space code to use kernel-specific declarations (e.g. IOCTLs, structure
|
|
||||||
declarations, constants, etc...). They are located in:
|
|
||||||
|
|
||||||
./kernel/common,
|
|
||||||
./kernel/arch-arm
|
|
||||||
./kernel/arch-x86
|
|
||||||
|
|
||||||
These headers have been generated by a tool (kernel/tools/update-all.py) to
|
|
||||||
only include the public definitions from the original Linux kernel headers.
|
|
||||||
|
|
||||||
If you want to know why and how this is done, read kernel/README.TXT to get
|
|
||||||
all the (gory) details.
|
|
||||||
|
|
||||||
|
|
||||||
PThread implementation:
|
|
||||||
|
|
||||||
Bionic's C library comes with its own pthread implementation bundled in.
|
|
||||||
This is different from other historical C libraries which:
|
|
||||||
|
|
||||||
- place it in an external library (-lpthread)
|
|
||||||
- play linker tricks with weak symbols at dynamic link time
|
|
||||||
|
|
||||||
The support for real-time features (a.k.a. -lrt) is also bundled in the
|
|
||||||
C library.
|
|
||||||
|
|
||||||
The implementation is based on futexes and strives to provide *very* short
|
|
||||||
code paths for common operations. Notable features are the following:
|
|
||||||
|
|
||||||
- pthread_mutex_t, pthread_cond_t are only 4 bytes each.
|
|
||||||
|
|
||||||
- Normal, recursive and error-check mutexes are supported, and the code
|
|
||||||
path is heavily optimized for the normal case, which is used most of
|
|
||||||
the time.
|
|
||||||
|
|
||||||
- Process-shared mutexes and condition variables are not supported.
|
|
||||||
Their implementation requires far more complexity and was absolutely
|
|
||||||
not needed for Android (which uses other inter-process synchronization
|
|
||||||
capabilities).
|
|
||||||
|
|
||||||
Note that they could be added in the future without breaking the ABI
|
|
||||||
by specifying more sophisticated code paths (which may make the common
|
|
||||||
paths slightly slower though).
|
|
||||||
|
|
||||||
- There is currently no support for read/write locks, priority-ceiling in
|
|
||||||
mutexes and other more advanced features. Again, the main idea being
|
|
||||||
that this was not needed for Android at all but could be added in the
|
|
||||||
future.
|
|
||||||
|
|
||||||
pthread_cancel():
|
|
||||||
|
|
||||||
pthread_cancel() will *not* be supported in Bionic, because doing this would
|
|
||||||
involve making the C library significantly bigger for very little benefit.
|
|
||||||
|
|
||||||
Consider that:
|
|
||||||
|
|
||||||
- A proper implementation must insert pthread cancellation checks in a lot
|
|
||||||
of different places of the C library. And conformance is very difficult
|
|
||||||
to test properly.
|
|
||||||
|
|
||||||
- A proper implementation must also clean up resources, like releasing
|
|
||||||
memory, or unlocking mutexes, properly if the cancellation happens in a
|
|
||||||
complex function (e.g. inside gethostbyname() or fprintf() + complex
|
|
||||||
formatting rules). This tends to slow down the path of many functions.
|
|
||||||
|
|
||||||
- pthread cancellation cannot stop all threads: e.g. it can't do anything
|
|
||||||
against an infinite loop
|
|
||||||
|
|
||||||
- pthread cancellation itself has short-comings and isn't very portable
|
|
||||||
(see http://advogato.org/person/slamb/diary.html?start=49 for example).
|
|
||||||
|
|
||||||
All of this is contrary to the Bionic design goals. If your code depends on
|
|
||||||
thread cancellation, please consider alternatives.
|
|
||||||
|
|
||||||
Note however that Bionic does implement pthread_cleanup_push() and
|
|
||||||
pthread_cleanup_pop(), which can be used to handle cleanups that happen when
|
|
||||||
a thread voluntarily exits through pthread_exit() or returning from its
|
|
||||||
main function.
|
|
||||||
|
|
||||||
|
|
||||||
pthread_once():
|
|
||||||
|
|
||||||
Do not call fork() within a callback provided to pthread_once(). Doing this
|
|
||||||
may result in a deadlock in the child process the next time it calls
|
|
||||||
pthread_once().
|
|
||||||
|
|
||||||
Also, you can't throw a C++ Exception from the callback (see C++ Exception
|
|
||||||
Support below).
|
|
||||||
|
|
||||||
The current implementation of pthread_once() lacks the necessary support of
|
|
||||||
multi-core-safe double-checked-locking (read and write barriers).
|
|
||||||
|
|
||||||
|
|
||||||
Thread-specific data
|
|
||||||
|
|
||||||
The thread-specific storage only provides for a bit less than 64
|
|
||||||
pthread_key_t objects to each process. The implementation provides 64 real
|
|
||||||
slots but also uses about 5 of them (exact number may depend on
|
|
||||||
implementation) for its own use (e.g. two slots are pre-allocated by the C
|
|
||||||
library to speed-up the Android OpenGL sub-system).
|
|
||||||
|
|
||||||
Note that Posix mandates a minimum of 128 slots, but we do not claim to be
|
|
||||||
Posix-compliant.
|
|
||||||
|
|
||||||
Except for the main thread, the TLS area is stored at the top of the stack.
|
|
||||||
See comments in bionic/libc/bionic/pthread.c for details.
|
|
||||||
|
|
||||||
At the moment, thread-local storage defined through the __thread compiler
|
|
||||||
keyword is not supported by the Bionic C library and dynamic linker.
|
|
||||||
|
|
||||||
|
|
||||||
Multi-core support
|
|
||||||
|
|
||||||
At the moment, Bionic does not provide or use read/write memory barriers.
|
|
||||||
This means that using it on certain multi-core systems might not be
|
|
||||||
supported, depending on its exact CPU architecture.
|
|
||||||
|
|
||||||
|
|
||||||
Android-specific features:
|
|
||||||
|
|
||||||
Bionic provides a small number of Android-specific features to its clients:
|
|
||||||
|
|
||||||
- access to system properties:
|
|
||||||
|
|
||||||
Android provides a simple shared value/key space to all processes on the
|
|
||||||
system. It stores a liberal number of 'properties', each of them being a
|
|
||||||
simple size-limited string that can be associated to a size-limited
|
|
||||||
string value.
|
|
||||||
|
|
||||||
The header <sys/system_properties.h> can be used to read system
|
|
||||||
properties and also defines the maximum size of keys and values.
|
|
||||||
|
|
||||||
- Android-specific user/group management:
|
|
||||||
|
|
||||||
There is no /etc/passwd or /etc/groups in Android. By design, it is
|
|
||||||
meant to be used by a single handset user. On the other hand, Android
|
|
||||||
uses the Linux user/group management features extensively to secure
|
|
||||||
process permissions, like access to various filesystem directories.
|
|
||||||
|
|
||||||
In the Android scheme, each installed application gets its own
|
|
||||||
uid_t/gid_t starting from 10000; lower numerical ids are reserved for
|
|
||||||
system daemons.
|
|
||||||
|
|
||||||
getpwnam() recognizes some hard-coded subsystems names (e.g. "radio")
|
|
||||||
and will translate them to their low-user-id values. It also recognizes
|
|
||||||
"app_1234" as the synthetic name of the application that was installed
|
|
||||||
with uid 10000 + 1234, which is 11234. getgrnam() works similarly
|
|
||||||
|
|
||||||
getgrouplist() will always return a single group for any user name,
|
|
||||||
which is the one passed as an input parameter.
|
|
||||||
|
|
||||||
getgrgid() will similarly only return a structure that contains a
|
|
||||||
single-element members list, corresponding to the user with the same
|
|
||||||
numerical value than the group.
|
|
||||||
|
|
||||||
See bionic/libc/bionic/stubs.c for more details.
|
|
||||||
|
|
||||||
- getservent()
|
|
||||||
|
|
||||||
There is no /etc/services on Android. Instead the C library embeds a
|
|
||||||
constant list of services in its executable, which is parsed on demand
|
|
||||||
by the various functions that depend on it. See
|
|
||||||
bionic/libc/netbsd/net/getservent.c and
|
|
||||||
bionic/libc/netbsd/net/services.h
|
|
||||||
|
|
||||||
The list of services defined internally might change liberally in the
|
|
||||||
future. This feature is mostly historically and is very rarely used.
|
|
||||||
|
|
||||||
The getservent() returns thread-local data. getservbyport() and
|
|
||||||
getservbyname() are also implemented in a similar fashion.
|
|
||||||
|
|
||||||
- getprotoent()
|
|
||||||
|
|
||||||
There is no /etc/protocol on Android. Bionic does not currently
|
|
||||||
implement getprotoent() and related functions. If added, it will
|
|
||||||
likely be done in a way similar to getservent()
|
|
||||||
|
|
||||||
DNS resolver:
|
|
||||||
|
|
||||||
Bionic uses a NetBSD-derived resolver library which has been modified in
|
|
||||||
the following ways:
|
|
||||||
|
|
||||||
- don't implement the name-server-switch feature (a.k.a. <nsswitch.h>)
|
|
||||||
|
|
||||||
- read /system/etc/resolv.conf instead of /etc/resolv.conf
|
|
||||||
|
|
||||||
- read the list of servers from system properties. the code looks for
|
|
||||||
'net.dns1', 'net.dns2', etc.. Each property should contain the IP
|
|
||||||
address of a DNS server.
|
|
||||||
|
|
||||||
these properties are set/modified by other parts of the Android system
|
|
||||||
(e.g. the dhcpd daemon).
|
|
||||||
|
|
||||||
the implementation also supports per-process DNS server list, using the
|
|
||||||
properties 'net.dns1.<pid>', 'net.dns2.<pid>', etc... Where <pid> stands
|
|
||||||
for the numerical ID of the current process.
|
|
||||||
|
|
||||||
- when performing a query, use a properly randomized Query ID (instead of
|
|
||||||
a incremented one), for increased security.
|
|
||||||
|
|
||||||
- when performing a query, bind the local client socket to a random port
|
|
||||||
for increased security.
|
|
||||||
|
|
||||||
- get rid of *many* unfortunate thread-safety issues in the original code
|
|
||||||
|
|
||||||
Bionic does *not* expose implementation details of its DNS resolver; the
|
|
||||||
content of <arpa/nameser.h> is intentionally blank. The resolver
|
|
||||||
implementation might change completely in the future.
|
|
||||||
|
|
||||||
|
|
||||||
PThread Real-Time Timers:
|
|
||||||
|
|
||||||
timer_create(), timer_gettime(), timer_settime() and timer_getoverrun() are
|
|
||||||
supported.
|
|
||||||
|
|
||||||
Bionic also now supports SIGEV_THREAD real-time timers (see timer_create()).
|
|
||||||
The implementation simply uses a single thread per timer, unlike GLibc which
|
|
||||||
uses complex heuristics to try to use the less threads possible when several
|
|
||||||
timers with compatible properties are used.
|
|
||||||
|
|
||||||
This means that if your code uses a lot of SIGEV_THREAD timers, your program
|
|
||||||
may consume a lot of memory. However, if your program needs many of these
|
|
||||||
timers, it'd better handle timeout events directly instead.
|
|
||||||
|
|
||||||
Other timers (e.g. SIGEV_SIGNAL) are handled by the kernel and use much less
|
|
||||||
system resources.
|
|
||||||
|
|
||||||
|
|
||||||
Binary Compatibility:
|
|
||||||
|
|
||||||
Bionic is *not* in any way binary-compatible with the GNU C Library, ucLibc
|
|
||||||
or any known Linux C library. This means several things:
|
|
||||||
|
|
||||||
- You cannot expect to build something against the GNU C Library headers and
|
|
||||||
have it dynamically link properly to Bionic later.
|
|
||||||
|
|
||||||
- You should *really* use the Android toolchain to build your program against
|
|
||||||
Bionic. The toolchain deals with many important details that are crucial
|
|
||||||
to get something working properly.
|
|
||||||
|
|
||||||
Failure to do so will usually result in the inability to run or link your
|
|
||||||
program, or even runtime crashes. Several random web pages on the Internet
|
|
||||||
describe how you can succesfully write a "hello-world" program with the
|
|
||||||
ARM GNU toolchain. These examples usually work by chance, if anything else,
|
|
||||||
and you should not follow these instructions unless you want to waste a lot
|
|
||||||
of your time in the process.
|
|
||||||
|
|
||||||
Note however that you *can* generate a binary that is built against the
|
|
||||||
GNU C Library headers and then statically linked to it. The corresponding
|
|
||||||
executable should be able to run (if it doesn't use dlopen()/dlsym())
|
|
||||||
|
|
||||||
|
|
||||||
Dynamic Linker:
|
|
||||||
|
|
||||||
Bionic comes with its own dynamic linker (just like ld.so on Linux really
|
|
||||||
comes from GLibc). This linker does not support all the relocations
|
|
||||||
generated by other GCC ARM toolchains.
|
|
||||||
|
|
||||||
|
|
||||||
C++ Exceptions Support:
|
|
||||||
|
|
||||||
At the moment, Bionic doesn't support C++ exceptions, what this really means
|
|
||||||
is the following:
|
|
||||||
|
|
||||||
- If pthread_once() is called with a C++ callback that throws an exception,
|
|
||||||
then the C library will keep the corresponding pthread_once_t mutex
|
|
||||||
locked. Any further call to pthread_once() will result in a deadlock.
|
|
||||||
|
|
||||||
A proper implementation should be able to register a C++ exception
|
|
||||||
cleanup handler before the callback to properly unlock the
|
|
||||||
pthread_once_t. Unfortunately this requires tricky assembly code that
|
|
||||||
is highly dependent on the compiler.
|
|
||||||
|
|
||||||
This feature is not planned to be supported anytime soon.
|
|
||||||
|
|
||||||
- The same problem may arise if you throw an exception within a callback
|
|
||||||
called from the C library. Fortunately, these cases are very rare in the
|
|
||||||
real-world, but any callback you provide to the C library should *not*
|
|
||||||
throw an exception.
|
|
||||||
|
|
||||||
- Bionic lacks a few support functions to have exception support work
|
|
||||||
properly.
|
|
||||||
|
|
||||||
System V IPCs:
|
|
||||||
|
|
||||||
Bionic intentionally does not provide support for System-V IPCs mechanisms,
|
|
||||||
like the ones provided by semget(), shmget(), msgget(). The reason for this
|
|
||||||
is to avoid denial-of-service. For a detailed rationale about this, please
|
|
||||||
read the file docs/SYSV-IPCS.TXT.
|
|
||||||
|
|
||||||
Include Paths:
|
|
||||||
|
|
||||||
The Android build system should automatically provide the necessary include
|
|
||||||
paths required to build against the C library headers. However, if you want
|
|
||||||
to do that yourself, you will need to add:
|
|
||||||
|
|
||||||
libc/arch-$ARCH/include
|
|
||||||
libc/include
|
|
||||||
libc/kernel/common
|
|
||||||
libc/kernel/arch-$ARCH
|
|
||||||
|
|
||||||
to your C include path.
|
|
@ -1,103 +0,0 @@
|
|||||||
Android does not support System V IPCs, i.e. the facilities provided by the
|
|
||||||
following standard Posix headers:
|
|
||||||
|
|
||||||
<sys/sem.h> /* SysV semaphores */
|
|
||||||
<sys/shm.h> /* SysV shared memory segments */
|
|
||||||
<sys/msg.h> /* SysV message queues */
|
|
||||||
<sys/ipc.h> /* General IPC definitions */
|
|
||||||
|
|
||||||
The reason for this is due to the fact that, by design, they lead to global
|
|
||||||
kernel resource leakage.
|
|
||||||
|
|
||||||
For example, there is no way to automatically release a SysV semaphore
|
|
||||||
allocated in the kernel when:
|
|
||||||
|
|
||||||
- a buggy or malicious process exits
|
|
||||||
- a non-buggy and non-malicious process crashes or is explicitely killed.
|
|
||||||
|
|
||||||
Killing processes automatically to make room for new ones is an
|
|
||||||
important part of Android's application lifecycle implementation. This means
|
|
||||||
that, even assuming only non-buggy and non-malicious code, it is very likely
|
|
||||||
that over time, the kernel global tables used to implement SysV IPCs will fill
|
|
||||||
up.
|
|
||||||
|
|
||||||
At that point, strange failures are likely to occur and prevent programs that
|
|
||||||
use them to run properly until the next reboot of the system.
|
|
||||||
|
|
||||||
And we can't ignore potential malicious applications. As a proof of concept
|
|
||||||
here is a simple exploit that you can run on a standard Linux box today:
|
|
||||||
|
|
||||||
--------------- cut here ------------------------
|
|
||||||
#include <sys/sem.h>
|
|
||||||
#include <sys/wait.h>
|
|
||||||
#include <unistd.h>
|
|
||||||
#include <stdio.h>
|
|
||||||
#include <stdlib.h>
|
|
||||||
#include <errno.h>
|
|
||||||
|
|
||||||
#define NUM_SEMAPHORES 32
|
|
||||||
#define MAX_FAILS 10
|
|
||||||
|
|
||||||
int main(void)
|
|
||||||
{
|
|
||||||
int counter = 0;
|
|
||||||
int fails = 0;
|
|
||||||
|
|
||||||
if (counter == IPC_PRIVATE)
|
|
||||||
counter++;
|
|
||||||
|
|
||||||
printf( "%d (NUM_SEMAPHORES=%d)\n", counter, NUM_SEMAPHORES);
|
|
||||||
|
|
||||||
for (;;) {
|
|
||||||
int ret = fork();
|
|
||||||
int status;
|
|
||||||
|
|
||||||
if (ret < 0) {
|
|
||||||
perror("fork:");
|
|
||||||
break;
|
|
||||||
}
|
|
||||||
if (ret == 0) {
|
|
||||||
/* in the child */
|
|
||||||
ret = semget( (key_t)counter, NUM_SEMAPHORES, IPC_CREAT );
|
|
||||||
if (ret < 0) {
|
|
||||||
return errno;
|
|
||||||
}
|
|
||||||
return 0;
|
|
||||||
}
|
|
||||||
else {
|
|
||||||
/* in the parent */
|
|
||||||
ret = wait(&status);
|
|
||||||
if (ret < 0) {
|
|
||||||
perror("waitpid:");
|
|
||||||
break;
|
|
||||||
}
|
|
||||||
if (status != 0) {
|
|
||||||
status = WEXITSTATUS(status);
|
|
||||||
fprintf(stderr, "child %d FAIL at counter=%d: %d\n", ret,
|
|
||||||
counter, status);
|
|
||||||
if (++fails >= MAX_FAILS)
|
|
||||||
break;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
counter++;
|
|
||||||
if ((counter % 1000) == 0) {
|
|
||||||
printf("%d\n", counter);
|
|
||||||
}
|
|
||||||
if (counter == IPC_PRIVATE)
|
|
||||||
counter++;
|
|
||||||
}
|
|
||||||
return 0;
|
|
||||||
}
|
|
||||||
--------------- cut here ------------------------
|
|
||||||
|
|
||||||
If you run it on a typical Linux distribution today, you'll discover that it
|
|
||||||
will quickly fill up the kernel's table of unique key_t values, and that
|
|
||||||
strange things will happen in some parts of the system, but not all.
|
|
||||||
|
|
||||||
(You can use the "ipcs -u" command to get a summary describing the kernel
|
|
||||||
tables and their allocations)
|
|
||||||
|
|
||||||
For example, in our experience, anything program launched after that that
|
|
||||||
calls strerror() will simply crash. The USB sub-system starts spoutting weird
|
|
||||||
errors to the system console, etc...
|
|
5
libc/upstream-freebsd/README.txt
Normal file
5
libc/upstream-freebsd/README.txt
Normal file
@ -0,0 +1,5 @@
|
|||||||
|
This directory contains upstream FreeBSD source. You should not edit these
|
||||||
|
files directly. Make fixes upstream and then pull down the new version of
|
||||||
|
the file.
|
||||||
|
|
||||||
|
TODO: write a script to make this process automated.
|
90
libm/NOTICE
90
libm/NOTICE
@ -225,96 +225,6 @@ SUCH DAMAGE.
|
|||||||
|
|
||||||
-------------------------------------------------------------------
|
-------------------------------------------------------------------
|
||||||
|
|
||||||
Copyright (c) 1993,94 Winning Strategies, Inc.
|
|
||||||
All rights reserved.
|
|
||||||
|
|
||||||
Redistribution and use in source and binary forms, with or without
|
|
||||||
modification, are permitted provided that the following conditions
|
|
||||||
are met:
|
|
||||||
1. Redistributions of source code must retain the above copyright
|
|
||||||
notice, this list of conditions and the following disclaimer.
|
|
||||||
2. Redistributions in binary form must reproduce the above copyright
|
|
||||||
notice, this list of conditions and the following disclaimer in the
|
|
||||||
documentation and/or other materials provided with the distribution.
|
|
||||||
3. All advertising materials mentioning features or use of this software
|
|
||||||
must display the following acknowledgement:
|
|
||||||
This product includes software developed by Winning Strategies, Inc.
|
|
||||||
4. The name of the author may not be used to endorse or promote products
|
|
||||||
derived from this software without specific prior written permission
|
|
||||||
|
|
||||||
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
||||||
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
||||||
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
||||||
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
||||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
||||||
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
||||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
||||||
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
||||||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
||||||
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
||||||
|
|
||||||
-------------------------------------------------------------------
|
|
||||||
|
|
||||||
Copyright (c) 1993,94 Winning Strategies, Inc.
|
|
||||||
All rights reserved.
|
|
||||||
|
|
||||||
Redistribution and use in source and binary forms, with or without
|
|
||||||
modification, are permitted provided that the following conditions
|
|
||||||
are met:
|
|
||||||
1. Redistributions of source code must retain the above copyright
|
|
||||||
notice, this list of conditions and the following disclaimer.
|
|
||||||
2. Redistributions in binary form must reproduce the above copyright
|
|
||||||
notice, this list of conditions and the following disclaimer in the
|
|
||||||
documentation and/or other materials provided with the distribution.
|
|
||||||
3. All advertising materials mentioning features or use of this software
|
|
||||||
must display the following acknowledgement:
|
|
||||||
This product includes software developed by Winning Strategies, Inc.
|
|
||||||
4. The name of the author may not be used to endorse or promote products
|
|
||||||
derived from this software without specific prior written permission.
|
|
||||||
|
|
||||||
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
||||||
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
||||||
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
||||||
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
||||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
||||||
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
||||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
||||||
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
||||||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
||||||
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
||||||
|
|
||||||
-------------------------------------------------------------------
|
|
||||||
|
|
||||||
Copyright (c) 1994 Winning Strategies, Inc.
|
|
||||||
All rights reserved.
|
|
||||||
|
|
||||||
Redistribution and use in source and binary forms, with or without
|
|
||||||
modification, are permitted provided that the following conditions
|
|
||||||
are met:
|
|
||||||
1. Redistributions of source code must retain the above copyright
|
|
||||||
notice, this list of conditions and the following disclaimer.
|
|
||||||
2. Redistributions in binary form must reproduce the above copyright
|
|
||||||
notice, this list of conditions and the following disclaimer in the
|
|
||||||
documentation and/or other materials provided with the distribution.
|
|
||||||
3. All advertising materials mentioning features or use of this software
|
|
||||||
must display the following acknowledgement:
|
|
||||||
This product includes software developed by Winning Strategies, Inc.
|
|
||||||
4. The name of the author may not be used to endorse or promote products
|
|
||||||
derived from this software without specific prior written permission.
|
|
||||||
|
|
||||||
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
||||||
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
||||||
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
||||||
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
||||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
||||||
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
||||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
||||||
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
||||||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
||||||
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
||||||
|
|
||||||
-------------------------------------------------------------------
|
|
||||||
|
|
||||||
Copyright (c) 2001-2011 The FreeBSD Project.
|
Copyright (c) 2001-2011 The FreeBSD Project.
|
||||||
All rights reserved.
|
All rights reserved.
|
||||||
|
|
||||||
|
@ -1,89 +0,0 @@
|
|||||||
Android Dynamic Linker Design Notes
|
|
||||||
===================================
|
|
||||||
|
|
||||||
Introduction:
|
|
||||||
-------------
|
|
||||||
|
|
||||||
This document provides several notes related to the design of the Android
|
|
||||||
dynamic linker.
|
|
||||||
|
|
||||||
|
|
||||||
Initialization and Termination functions:
|
|
||||||
-----------------------------------------
|
|
||||||
|
|
||||||
The Unix Sys V Binary Interface standard states that an
|
|
||||||
executable can have the following entries in its .dynamic
|
|
||||||
section:
|
|
||||||
|
|
||||||
DT_INIT
|
|
||||||
Points to the address of an initialization function
|
|
||||||
that must be called when the file is loaded.
|
|
||||||
|
|
||||||
DT_INIT_ARRAY
|
|
||||||
Points to an array of function addresses that must be
|
|
||||||
called, in-order, to perform initialization. Some of
|
|
||||||
the entries in the array can be 0 or -1, and should
|
|
||||||
be ignored.
|
|
||||||
|
|
||||||
Note: this is generally stored in a .init_array section
|
|
||||||
|
|
||||||
DT_INIT_ARRAYSZ
|
|
||||||
The size of the DT_INITARRAY, if any
|
|
||||||
|
|
||||||
DT_FINI
|
|
||||||
Points to the address of a finalization function which
|
|
||||||
must be called when the file is unloaded or the process
|
|
||||||
terminated.
|
|
||||||
|
|
||||||
DT_FINI_ARRAY
|
|
||||||
Same as DT_INITARRAY but for finalizers. Note that the
|
|
||||||
functions must be called in reverse-order though
|
|
||||||
|
|
||||||
Note: this is generally stored in a .fini_array section
|
|
||||||
|
|
||||||
DT_FINI_ARRAYSZ
|
|
||||||
Size of FT_FINIARRAY
|
|
||||||
|
|
||||||
DT_PREINIT_ARRAY
|
|
||||||
An array similar to DT_INIT_ARRAY which must *only* be
|
|
||||||
present in executables, not shared libraries, which contains
|
|
||||||
a list of functions that need to be called before any other
|
|
||||||
initialization function (i.e. DT_INIT and/or DT_INIT_ARRAY)
|
|
||||||
in the executable or any of its libraries.
|
|
||||||
|
|
||||||
Note: this is generally stored in a .preinit_array section
|
|
||||||
|
|
||||||
DT_PREINIT_ARRAYSZ
|
|
||||||
The size of DT_PREINIT_ARRAY
|
|
||||||
|
|
||||||
If both a DT_INIT and DT_INITARRAY entry are present, the DT_INIT
|
|
||||||
function must be called before the DT_INITARRAY functions.
|
|
||||||
|
|
||||||
Consequently, the DT_FINIARRAY must be parsed in reverse order before
|
|
||||||
the DT_FINI function, if both are available.
|
|
||||||
|
|
||||||
Note that the implementation of static C++ constructors is very
|
|
||||||
much processor dependent, and may use different ELF sections.
|
|
||||||
|
|
||||||
On the ARM (see "C++ ABI for ARM" document), the static constructors
|
|
||||||
must be called explicitly from the DT_INIT_ARRAY, and each one of them
|
|
||||||
shall register a destructor by calling the special __eabi_atexit()
|
|
||||||
function (provided by the C library). The DT_FINI_ARRAY is not used
|
|
||||||
by static C++ destructors.
|
|
||||||
|
|
||||||
On x86, the lists of constructors and destructors are placed in special
|
|
||||||
sections named ".ctors" and ".dtors", and the DT_INIT / DT_FINI functions
|
|
||||||
are in charge of calling them explicitly.
|
|
||||||
|
|
||||||
|
|
||||||
Debugging:
|
|
||||||
----------
|
|
||||||
|
|
||||||
You can increase the verbosity of debug traces by defining the LD_DEBUG
|
|
||||||
environment variable to a numeric value from 0 to 2 (corresponding to
|
|
||||||
INFO, TRACE, and DEBUG calls in the source). This will only
|
|
||||||
affect new processes being launched.
|
|
||||||
|
|
||||||
By default, traces are sent to logcat, with the "linker" tag. You can
|
|
||||||
change this to go to stdout instead by setting the definition of
|
|
||||||
LINKER_DEBUG_TO_LOG to 0 in "linker_debug.h".
|
|
@ -31,10 +31,16 @@
|
|||||||
|
|
||||||
#include <stdio.h>
|
#include <stdio.h>
|
||||||
|
|
||||||
/* set LINKER_DEBUG_TO_LOG to 1 to send the logs to logcat,
|
// You can increase the verbosity of debug traces by defining the LD_DEBUG
|
||||||
* or 0 to use stdout instead.
|
// environment variable to a numeric value from 0 to 2 (corresponding to
|
||||||
*/
|
// INFO, TRACE, and DEBUG calls in the source). This will only
|
||||||
|
// affect new processes being launched.
|
||||||
|
|
||||||
|
// By default, traces are sent to logcat, with the "linker" tag. You can
|
||||||
|
// change this to go to stdout instead by setting the definition of
|
||||||
|
// LINKER_DEBUG_TO_LOG to 0.
|
||||||
#define LINKER_DEBUG_TO_LOG 1
|
#define LINKER_DEBUG_TO_LOG 1
|
||||||
|
|
||||||
#define TRACE_DEBUG 1
|
#define TRACE_DEBUG 1
|
||||||
#define DO_TRACE_LOOKUP 1
|
#define DO_TRACE_LOOKUP 1
|
||||||
#define DO_TRACE_RELO 1
|
#define DO_TRACE_RELO 1
|
||||||
|
Loading…
Reference in New Issue
Block a user