Boost Android Native Stack Tracing: Faster Unwind Techniques and QUT

Introduces a slightly different native backtrace technique on Android that, while supporting Android ART unwind, trades a few traceable scenarios for performance gains. The approach has advantages and limitations, suitable for certain scenarios.

How is stack unwinding usually done in Android native?

There are essentially two common methods: one based on the frame‑pointer (fp) register and another based on exception handling (EH) or DWARF debug information.

1. Frame‑pointer‑based unwinder (fp‑based)

If the code is compiled with -fno-omit-frame-pointer, the compiler reserves a specific register as the frame pointer, storing the start address of the current function's stack frame. On ARM, fp points to a stack area that contains the previous frame's fp and the return address. On 64‑bit the fp register is x29; on 32‑bit it is r7 (Thumb) or r11 (ARM).

fp‑based unwinding offers the best performance because it reads memory contiguously, but it has drawbacks: on 32‑bit ARM the fp may be omitted or inaccurate in some cases, and it cannot unwind through JNI or OAT code that does not follow the fp convention.

2. Exception‑handling / DWARF‑based unwinding

This method relies on the .eh_frame or .debug_frame sections of an ELF file, which contain compact unwind tables. When execution reaches a particular program counter (pc), the tables describe how to restore registers, including the return address.

The DWARF example shows how each line of a function (e.g., foo) records the recovery rule for registers R0‑R8. The “CFA” column represents a virtual stack pointer that points to the base of the current frame.

Unwind tables allow us to locate the start of each frame and compute the saved return address, iterating until the whole call stack is recovered.

On 32‑bit ARM, a separate Exception Handling mechanism stores data in .ARM.exidx and .ARM.extab. The unwind instruction set defined by ARM is simpler than DWARF.

Running arm-linux-androideabi-readelf -u lib<your32bit>.so shows the ARM unwind tables for 32‑bit libraries.

How to improve the unwinding implementation

EH‑based libraries incur a noticeable performance cost. When a frame pointer is available, fp‑based unwinding is fastest, but many 32‑bit libraries lack fp (e.g., when hooking or tracing closed‑source .so files). In such cases, libraries like libunwind or libunwindstack that rely on EH are the only option.

Moreover, fp‑based unwinding cannot cross JNI functions or system‑generated OAT code because those do not follow the fp convention.

What can be optimized?

Unwind tables restore the full register state for each frame, which is unnecessary for pure stack tracing. By discarding registers that are not needed and simplifying register‑calculation rules, performance can be greatly improved.

For example, the .ARM.exidx entry can be reduced to compute only the virtual stack pointer (vsp) offset needed to retrieve the return address register r14 (lr):

The calculation simplifies to vsp = vsp + 320; r14 = [vsp - 4];.

Unwinding through JNI, OAT, and JIT

1. Through JNI

JNI functions save the frame‑pointer base in a specific register (r10 on 32‑bit, x28 on 64‑bit). Restoring that register allows unwinding across JNI frames.

2. Through OAT

OAT files are ELF binaries. Since Android 8.0 they contain a .debug_frame section; earlier versions require the system property debug.generate-debug-info=true. The OAT code also stores the Dex PC in r4 (32‑bit) or x19/x20 (64‑bit), enabling retrieval of Java method signatures.

3. Through JIT

When a Java method is JIT‑compiled, its machine code resides in the JIT cache, which is not an ELF file. Debug information is provided via __jit_debug_descriptor starting from Android 8.0.

Quicken Unwind Table (QUT)

After simplifying .eh_frame, .debug_frame, and .ARM.exidx, we generate a compact QUT that can be interpreted at runtime.

Only registers of interest (fp, Dex PC, JNI base, lr) have dedicated instructions.

Performance

Benchmarks show QUT backtraces are 15‑30× faster than EH‑based unwinding (libunwindstack) for a 60‑frame stack, and only 4‑5× slower than pure fp unwinding for an 18‑frame stack that does not cross the VM.

Coverage

Testing on several vendor ROMs and the WeChat app shows the unsupported scenarios are rare.

Generating QUT data

QUT can be generated at build time (increasing package size) or at runtime (preferred). Most libraries generate QUT in tens of milliseconds; large OAT files like boot‑framework.oat may take minutes.

The resulting data occupies about 10‑20 MiB for a full system plus the WeChat libraries, with roughly 10 MiB resident after mmap.

Advantages and limitations

QUT offers a 15‑30× speed boost over traditional unwind tables but remains slower than fp‑based unwinding (4‑5×). It excels in 32‑bit ARM environments where fp usage is complex.

QUT can also retrieve Java stacks (by unwinding JNI/OAT/JIT). Its performance for Java stack extraction is comparable to native Java‑stack methods, with the added benefit of not altering VM state.

QUT generation requires a warm‑up phase and depends on the presence of EH information in ELF files.

Implementation can be built on top of libunwindstack; the source has been back‑ported to Matrix v1.0 ( ).