RFC: Support building bpftrace for Android/AArch64

Summary

The bpftrace mainline currently does not provide a supported Android build environment. The known Android-related environment is:

https://github.com/facebookexperimental/ExtendedAndroidTools/tree/main

It depends on the Android NDK and requires additional adaptation. It cannot be used as a drop-in build environment for the latest bpftrace mainline code.

This RFC proposes adding a separate, reproducible cross-build environment for AArch64 bpftrace. It builds bpftrace and its user-space dependencies from pinned source revisions and can produce a fully-static executable suitable for deployment on an Android AArch64 device.

The proposal does not modify bpftrace or the source code of its dependencies. It adds a build environment and deployment workflow around the existing source trees.

Motivation

An Android device may not provide compatible development packages or the matching LLVM, Clang, libbpf, BCC, elfutils, libpcap, and other libraries required by bpftrace. A dynamically linked binary therefore requires additional target-side library packaging and compatibility work.

A fully-static executable avoids requiring those bpftrace-specific shared libraries on the target. This provides a practical deployment path for devices where building or installing the complete dependency set is not possible.

Proposed workflow

The prototype provides a one-command build:

./scripts/build-all.sh

It downloads pinned sources, builds the dependencies from source, cross-compiles LLVM/Clang and bpftrace for AArch64, performs an ELF audit, and creates a deployment archive suitable for adb push. All build steps use -j3.

Cross-build-specific behavior is kept in external build scripts, an external CMake dependency configuration, a static-link wrapper, and staging scripts. The normal native bpftrace build remains unchanged.

Source-code impact

The prototype does not modify:

• bpftrace C++ source code or upstream CMake source files;
• LLVM/Clang source code;
• libbpf, BCC, elfutils, libpcap, blazesym, or other dependency source code.

The user-space dependencies are built from source. The final static binary contains the required static archives, including libelf.a, and does not require libelf.so.1 or other bpftrace-specific shared libraries at runtime.

Prototype and Android test

The prototype produces an AArch64 executable with no dynamic section, interpreter, or DT_NEEDED entries. It has been substantially validated with an Android AArch64 device.

The preliminary test was performed using:

adb push staging/bpftrace-aarch64/bin/bpftrace /data/bpftrace
adb shell chmod 755 /data/bpftrace
adb shell /data/bpftrace --version
adb shell /data/bpftrace --help
adb shell "/data/bpftrace -e 'tracepoint:sched:sched* { @[probe] = count(); } interval:s:5 { exit(); }'"

Attached 37 probes @[tracepoint:sched:sched_kthread_stop_ret]: 1 @[tracepoint:sched:sched_kthread_stop]: 2 @[tracepoint:sched:sched_wait_task]: 3 @[tracepoint:sched:sched_process_exec]: 7 @[tracepoint:sched:sched_prepare_exec]: 7 @[tracepoint:sched:sched_process_wait]: 15 @[tracepoint:sched:sched_pi_setprio]: 96

readelf -d bpftrace

There is no dynamic section in this file.

Platform scope

The initial prototype uses an AArch64 GNU/Linux cross toolchain and evaluates the resulting executable on Android. AArch64 GNU/Linux/glibc and Android NDK/bionic are different targets and should not be treated as identical. Official Android NDK/bionic support may require a separate toolchain configuration.

Questions

1. Is Android/AArch64 cross compilation a use case the bpftrace project wants to support?
2. Should this build environment live in the bpftrace repository or in a separate packaging/build repository?
3. Is a fully-static executable a useful supported deployment option?
4. Should Android NDK/bionic and AArch64 GNU/Linux/glibc be treated as separate targets?
5. Is an external build environment preferable to changes in bpftrace's upstream CMake configuration?

The prototype is intended to demonstrate the feasibility of this approach. If the direction is acceptable, a follow-up proof-of-concept pull request can provide implementation details, documentation, and tests linked to this RFC.