From 0493a6f7be42e22d68e1d6ddb8eb2edaf818756f Mon Sep 17 00:00:00 2001 From: Elliott Hughes Date: Thu, 7 Mar 2013 11:48:58 -0800 Subject: [PATCH] Regenerate NOTICE files. Also clean up some obsolete cruft. Change-Id: Iec3b36f6607f7a08b72de99294ed5b6cd910dd5f --- ABI-bugs.txt | 15 ++ libc/NOTICE | 28 +++ libc/README | 54 ----- libc/SYSCALLS.TXT | 5 +- libc/docs/OVERVIEW.TXT | 400 ------------------------------- libc/docs/SYSV-IPC.TXT | 103 -------- libc/upstream-freebsd/README.txt | 5 + libm/NOTICE | 90 ------- linker/README.TXT | 89 ------- linker/linker_debug.h | 12 +- 10 files changed, 61 insertions(+), 740 deletions(-) create mode 100644 ABI-bugs.txt delete mode 100644 libc/README delete mode 100644 libc/docs/OVERVIEW.TXT delete mode 100644 libc/docs/SYSV-IPC.TXT create mode 100644 libc/upstream-freebsd/README.txt delete mode 100644 linker/README.TXT diff --git a/ABI-bugs.txt b/ABI-bugs.txt new file mode 100644 index 000000000..83ee95200 --- /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 3be0f85c2..730fa4681 100644 --- a/libc/NOTICE +++ b/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, All rights reserved. diff --git a/libc/README b/libc/README deleted file mode 100644 index d92d85dc6..000000000 --- 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 dc139bd93..2a2561864 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 753e48a5b..000000000 --- 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 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 . - - 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 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. ) - - - 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.', 'net.dns2.', etc... Where 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 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 5a3eef0d7..000000000 --- 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: - - /* SysV semaphores */ - /* SysV shared memory segments */ - /* SysV message queues */ - /* 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 -#include -#include -#include -#include -#include - -#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 000000000..fbfc04ab2 --- /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 06a100c90..d6d0ad9f4 100644 --- a/libm/NOTICE +++ b/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. All rights reserved. diff --git a/linker/README.TXT b/linker/README.TXT deleted file mode 100644 index e75823e24..000000000 --- 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 bf9ef921f..6aeb9ac1e 100644 --- a/linker/linker_debug.h +++ b/linker/linker_debug.h @@ -31,10 +31,16 @@ #include -/* 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