Merge "Remove AOSP preupload hook." into main
diff --git a/README.md b/README.md
index 953e983..4b7e42d 100644
--- a/README.md
+++ b/README.md
@@ -268,36 +268,14 @@
https://android-review.googlesource.com/c/platform/bionic/+/2073827
### Debugging tips
-1. Key error for a new codename in libc/libc.map.txt
-e.g. what you add in libc/libc.map.txt is:
+If a test fails to build with an undefined symbol error,
+this is most likely the _host_ reference test against glibc,
+and you need to add an `#if defined(__GLIBC__)` to the test.
+(Search for existing examples to copy & paste,
+in particular to make sure you include the `GTEST_SKIP()`.)
-```
-LIBC_V { # introduced=Vanilla
- global:
- xxx; // the new system call you add
-} LIBC_U;
-```
-
-The error output is:
-
-```
-Traceback (most recent call last):
- File "/path/tp/out/soong/.temp/Soong.python_qucjwd7g/symbolfile/__init__.py", line 171,
- in decode_api_level_tag
- decoded = str(decode_api_level(value, api_map))
- File "/path/to/out/soong/.temp/Soong.python_qucjwd7g/symbolfile/__init__.py", line 157,
- in decode_api_level
- return api_map[api]
-KeyError: 'Vanilla'
-```
-
-Solution: Ask in the team and wait for the update.
-
-2. Use of undeclared identifier of the new system call in the test
-
-Possible Solution: Check everything ready in the files mentioned above first.
-Maybe glibc matters. Follow the example and try #if defined(__GLIBC__).
+When we switch to musl for the host libc, this should be less of a problem.
## Updating kernel header files
@@ -314,9 +292,12 @@
## Updating tzdata
-This is handled by the libcore team, because they own icu, and that needs to be
-updated in sync with bionic). See
-[system/timezone/README.android](https://android.googlesource.com/platform/system/timezone/+/main/README.android).
+Tzdata updates are now handled by the libcore team because it needs to be
+updated in sync with icu's copy of the data, and they own that.
+
+See
+[system/timezone/README.android](https://android.googlesource.com/platform/system/timezone/+/main/README.android)
+for more information.
## Verifying changes
@@ -336,14 +317,68 @@
directory `benchmarks/` containing benchmarks, and that has its own
documentation on [running the benchmarks](benchmarks/README.md).
+### Building
+
+We assume you've already checked out the Android source tree.
+
+To build, make sure you're in the right directory and you've set up your environment:
+
+ $ cd main # Or whatever you called your Android source tree.
+ $ source build/envsetup.sh
+
+Then choose an appropriate "lunch". If you're not testing on a device,
+two choices are particularly useful.
+
+If you want to be able to run tests and benchmarks directly on your x86-64
+host machine, use:
+
+ $ lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
+
+Alternatively, if you want to (say) check generated arm64 code without having
+a specific device in mind, use:
+
+ $ lunch aosp_cf_arm64_phone-trunk_staging-userdebug
+
+Note that in both cases,
+these targets will also build the corresponding 32-bit variant.
+See below for where the 64-bit and 32-bit files end up.
+
+See [Build Android](https://source.android.com/docs/setup/build/building)
+for more details.
+
### Device tests
- $ mma # In $ANDROID_ROOT/bionic.
- $ adb root && adb remount && adb sync
+Once you've completed that setup, you can build:
+
+ $ cd bionic
+ $ mm
+
+This will build everything: bionic, the benchmarks, and the tests
+(and all the dependencies).
+
+If you want to test on a device,
+the first time after flashing your device,
+you'll need to remount the filesystems to be writable:
+
+ $ adb root
+ $ adb remount
+ $ adb reboot
+ $ adb wait-for-device
+ $ adb root
+ $ adb remount
+
+Then you can sync your locally built files across:
+
+ $ adb sync
+
+And then you can run the 32-bit tests (dynamic or static):
+
$ adb shell /data/nativetest/bionic-unit-tests/bionic-unit-tests
$ adb shell \
/data/nativetest/bionic-unit-tests-static/bionic-unit-tests-static
- # Only for 64-bit targets
+
+Or the 64-bit tests (dynamic or static):
+
$ adb shell /data/nativetest64/bionic-unit-tests/bionic-unit-tests
$ adb shell \
/data/nativetest64/bionic-unit-tests-static/bionic-unit-tests-static
@@ -380,15 +415,52 @@
### Host tests
The host tests require that you have `lunch`ed either an x86 or x86_64 target.
+
+(Obviously, in theory you could build for arm64 and run on an arm64 host,
+but we currently only support x86-64 host builds.)
+
+For example:
+
+ $ lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
+
+Then build as normal:
+
+ $ cd bionic
+ $ mm
+
Note that due to ABI limitations (specifically, the size of pthread_mutex_t),
-32-bit bionic requires PIDs less than 65536. To enforce this, set /proc/sys/kernel/pid_max
-to 65536.
+32-bit bionic requires PIDs less than 65536.
+To enforce this, set /proc/sys/kernel/pid_max to 65536.
+(The tests will remind you if you forget.)
+
+The easiest way to run is to use our provided script.
+
+To run the 32-bit tests on the host:
$ ./tests/run-on-host.sh 32
- $ ./tests/run-on-host.sh 64 # For x86_64-bit *targets* only.
+
+To run the 64-bit tests on the host:
+
+ $ ./tests/run-on-host.sh 64
You can supply gtest flags as extra arguments to this script.
+This script starts by running build/run-on-host.sh which -- despite the name --
+is actually a script to set up your host to look more like an Android device.
+In particular, it creates a /system directory with appropriate symlinks to your
+"out" directory.
+
+An alternative is to run the static binaries directly from your "out" directory.
+
+To run the static 32-bit tests:
+
+ $ ../out/target/product/vsoc_x86_64/data/nativetest/bionic-unit-tests-static/bionic-unit-tests-static
+
+To run the static 64-bit tests:
+
+ $ ../out/target/product/vsoc_x86_64/data/nativetest64/bionic-unit-tests-static/bionic-unit-tests-static
+
+
### Against glibc
As a way to check that our tests do in fact test the correct behavior (and not