Bionic

This document is a high-level overview of making changes to bionic itself. If you're trying to use bionic, or want more in-depth information about some part of the implementation, see all the bionic documentation. The math library. Traditionally Unix systems kept stuff like sin(3) and cos(3) in a separate library to save space in the days before shared libraries. The dynamic linker interface library. This is actually just a bunch of stubs that the dynamic linker replaces with pointers to its own implementation at runtime. This is where stuff like dlopen(3) lives. The C++ ABI support functions. The C++ compiler doesn't know how to implement thread-safe static initialization and the like, so it just calls functions that are supplied by the system. Stuff like cxa guard acquire and cxa pure virtual live here. The dynamic linker. When you run a dynamically-linked executable, its ELF file has a DT INTERP entry that says "use the following program to start me". On Android, that's either linker or linker64 (depending on whether it's a 32-bit or 64-bit executable). It's responsible for loading the ELF executable into memory and resolving references to symbols (so that when your code tries to jump to fopen(3) , say, it lands in the right place). The tests/ directory contains unit tests. Roughly arranged as one file per publicly-exported header file. tests/headers/ contains compile-only tests that just check that things are in the headers, whereas the "real" tests check actual behavior . The first question you should ask is "should I add a libc wrapper for this system call?". The answer is usually "no". The answer may be "yes" if the system call has three/four distinct users in different projects, and there isn't a more specific higher-level library that would make more sense as the place to add the wrapper. 1. Add an entry (or entries, in some cases) to SYSCALLS.TXT. See SYSCALLS.TXT itself for documentation on the format. See also the notes below for how to deal with tricky cases like off t . 2. Find the right header file to work in by looking up your system call on man7.org. (If there's no header file given, see the points above about whether we should really be adding this or not!) 3. Add constants (and perhaps types) to the appropriate header file. Note that you should check to see whether the constants are already in kernel uapi header files, in which case you just need to make sure that the appropriate header file in libc/include/ include s the relevant linux/ file or files. 4. Add function declarations to the appropriate header file. Don't forget to include the appropriate INTRODUCED IN() , with the right API level for the first release your system call wrapper will be in. See libc/include/android/api level.h for the API levels. If the header file doesn't exist, copy all of libc/include/sys/sysinfo.h into your new file it's a good short example to start from. Note also our style for naming arguments: always use two leading underscores (so developers are free to use any of the unadorned names as macros without breaking things), avoid abbreviations, and ideally try to use the same name as an existing system call (to reduce the amount of English vocabulary required by people who just want to use the function signatures). If there's a similar function already in the C library, check what names it's used. Finally, prefer the void orthography we use over the void you'll see on man7.org.) 5. Add basic documentation to the header file. Again, the existing libc/include/sys/sysinfo.h is a good short example that shows the expected style. Most of the detail should actually be left to the man7.org page, with only a brief one-sentence explanation (usually based on the description in the NAME section of the man page) in our documentation. Always include the return value/error reporting details (you can find out what the system call returns from the RETURN VALUE of the man page), but try to match the wording and style wording from our