Lines Matching refs:to
6 This document is a high-level overview of making changes to bionic itself.
7 If you're trying to _use_ bionic, or want more in-depth information about
19 `cos(3)` in a separate library to save space in the days before shared
25 that the dynamic linker replaces with pointers to its own implementation at
30 The C++ ABI support functions. The C++ compiler doesn't know how to implement
38 has a `DT_INTERP` entry that says "use the following program to start me". On
41 into memory and resolving references to symbols (so that when your code tries to
42 jump to `fopen(3)`, say, it lands in the right place).
91 # are in. Those are left to individual kernels' ABIs. In an effort to --
96 # of extra stuff that isn't available to userspace). We import the latest
100 # The generate_uapi_headers.sh script should be used to go from a kernel
101 # tree to external/kernel-headers/ --- this takes care of the
103 # used to regenerate bionic's copy from external/kernel-headers/.
121 # accident (because it wouldn't have been easy to import just the tiny
126 # but in order to actually be able to compile this code in our tree
127 # _without_ making modifications to the source files directly, we also
131 # This is where we keep the hacks necessary to build BSD source
140 # legacy mess that needs to be sorted out, either by replacing it with
142 # switching the file to C++ and cleaning it up.
145 # The code that implements the functionality to enable debugging of
149 # These are legacy files of dubious provenance. We're working to clean
153 # Various tools used to maintain bionic.
157 # to Android's use of a single file (with corresponding index) to contain
177 library that would make more sense as the place to add the wrapper.
184 1. Add an entry (or entries, in some cases) to SYSCALLS.TXT.
186 See also the notes below for how to deal with tricky cases like `off_t`.
187 2. Find the right header file to work in by looking up your system call
191 3. Add constants (and perhaps types) to the appropriate header file.
192 Note that you should check to see whether the constants are already in
193 kernel uapi header files, in which case you just need to make sure that
196 4. Add function declarations to the appropriate header file. Don't forget
197 to include the appropriate `__INTRODUCED_IN()`, with the right API level
201 into your new file --- it's a good short example to start from.
204 underscores (so developers are free to use any of the unadorned names as
205 macros without breaking things), avoid abbreviations, and ideally try to
206 use the same name as an existing system call (to reduce the amount of
207 English vocabulary required by people who just want to use the function
211 5. Add basic documentation to the header file. Again, the existing
215 Most of the detail should actually be left to the man7.org page, with
220 but try to match the wording and style wording from _our_ existing
221 documentation; we're trying to minimize the amount of English readers
222 need to understand by using the exact same wording where possible).
223 Explicitly say which version of Android the function was added to in
229 6. Add the function name to the correct section in libc/libc.map.txt; it'll
230 be near the end of the file. You may need to add a new section if you're
231 the first to add a system call to this version of Android.
232 7. Add a basic test. Don't try to test everything; concentrate on just testing
243 the header file, and that the change to libc.map.txt from step 5 is
244 correct. (You can use strace(1) manually to confirm that the correct
247 For testing the *kernel* side of things, we should prefer to rely on
249 want to check that external/ltp does contain tests for the syscall you're
254 argument such as `off64_t` (a *pointer* to a 64-bit argument is fine, since
256 size of the thing they point to). Whenever you have a function that takes
257 `off_t` or `off64_t`, you'll need to consider whether you actually need a foo()
259 implemented as two different system calls. It's usually easiest to find a
260 similar system call and copy and paste from that. You'll definitely need to test
263 feasible to write a working test for the interesting cases -- offsets larger
265 only purpose is to give you patterns to look for when run under strace(1).)
289 File "/path/to/out/soong/.temp/Soong.python_qucjwd7g/symbolfile/__init__.py", line 157,
306 1. Use generate_uapi_headers.sh to go from a Linux source tree to appropriate
308 2. Run update_all.py to scrub those headers and import them into bionic.
310 Note that if you're actually just trying to expose device-specific headers to
317 This is handled by the libcore team, because they own icu, and that needs to be
324 If you make a change that is likely to have a wide effect on the tree (such as a
362 we log in this case to prevent accidents!). Obviously, if the test can be
363 rewritten to not require root, that's an even better solution.
367 all tests. In order for this to continue to work, all architectures must
372 but in cases where you really have to run CTS:
383 Note that due to ABI limitations (specifically, the size of pthread_mutex_t),
385 to 65536.
390 You can supply gtest flags as extra arguments to this script.
394 As a way to check that our tests do in fact test the correct behavior (and not
395 just the behavior we think is correct), it is possible to run the tests against
402 Another way to verify test behavior is to run against musl on the host. glibc
403 musl don't always match, so this can be a good way to find the more complicated
408 Note: the alternate OUT_DIR is used to avoid causing excessive rebuilding when
416 running, follow the instructions at the top of the file to rebuild bionic with
419 ## Attaching GDB to the tests
421 Bionic's test runner will run each test in its own process by default to prevent
425 However, this also makes it difficult to run the tests under GDB. To prevent