Regenerate NOTICE files.
Also clean up some obsolete cruft.
Change-Id: Iec3b36f6607f7a08b72de99294ed5b6cd910dd5f
diff --git a/ABI-bugs.txt b/ABI-bugs.txt
new file mode 100644
index 0000000..83ee952
--- /dev/null
+++ b/ABI-bugs.txt
@@ -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
diff --git a/libc/NOTICE b/libc/NOTICE
index 3be0f85..730fa46 100644
--- a/libc/NOTICE
+++ b/libc/NOTICE
@@ -4030,6 +4030,34 @@
-------------------------------------------------------------------
+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,
All rights reserved.
diff --git a/libc/README b/libc/README
deleted file mode 100644
index d92d85d..0000000
--- a/libc/README
+++ /dev/null
@@ -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.
diff --git a/libc/SYSCALLS.TXT b/libc/SYSCALLS.TXT
index dc139bd..2a25618 100644
--- a/libc/SYSCALLS.TXT
+++ b/libc/SYSCALLS.TXT
@@ -25,7 +25,10 @@
# - 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
#
-# 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
diff --git a/libc/docs/OVERVIEW.TXT b/libc/docs/OVERVIEW.TXT
deleted file mode 100644
index 753e48a..0000000
--- a/libc/docs/OVERVIEW.TXT
+++ /dev/null
@@ -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.
diff --git a/libc/docs/SYSV-IPC.TXT b/libc/docs/SYSV-IPC.TXT
deleted file mode 100644
index 5a3eef0..0000000
--- a/libc/docs/SYSV-IPC.TXT
+++ /dev/null
@@ -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...
diff --git a/libc/upstream-freebsd/README.txt b/libc/upstream-freebsd/README.txt
new file mode 100644
index 0000000..fbfc04a
--- /dev/null
+++ b/libc/upstream-freebsd/README.txt
@@ -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.
diff --git a/libm/NOTICE b/libm/NOTICE
index 06a100c..d6d0ad9 100644
--- a/libm/NOTICE
+++ b/libm/NOTICE
@@ -225,96 +225,6 @@
-------------------------------------------------------------------
-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.
All rights reserved.
diff --git a/linker/README.TXT b/linker/README.TXT
deleted file mode 100644
index e75823e..0000000
--- a/linker/README.TXT
+++ /dev/null
@@ -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".
diff --git a/linker/linker_debug.h b/linker/linker_debug.h
index bf9ef92..6aeb9ac 100644
--- a/linker/linker_debug.h
+++ b/linker/linker_debug.h
@@ -31,10 +31,16 @@
#include <stdio.h>
-/* set LINKER_DEBUG_TO_LOG to 1 to send the logs to logcat,
- * or 0 to use stdout instead.
- */
+// 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.
#define LINKER_DEBUG_TO_LOG 1
+
#define TRACE_DEBUG 1
#define DO_TRACE_LOOKUP 1
#define DO_TRACE_RELO 1
