Is NDK23 missing libunwind.h?

[aronyu79]

Here it states that libunwind is the default unwinder for NDK23?
https://github.com/android/ndk/wiki/Changelog-r23#changes
https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#Unwinding

Am I supposed to be able to use this from my own app? In that case is libunwind.h missing from the NDK?

[DanAlbert]

#925

[enh-google]

Am I supposed to be able to use this from my own app? In that case is libunwind.h missing from the NDK?

note that the NDK release notes actually say LLVM libunwind is the default. that's not the same as https://www.nongnu.org/libunwind/.

so i'd expect <unwind.h> to work, but not <libunwind.h>.

if you actually want the higher-level <execinfo.h>, that's in bionic from Android T.

[aronyu79]

Ok I didn't know they were different! Thanks! I do see the libunwind symbols in libunwind.a tho. But reading HP docs it sounds like the unwind.h apis uses these internally perhaps? https://bcain-llvm.readthedocs.io/projects/libunwind/en/latest/

But basically the APIs are different but the implementation is the same I guess,

[enh-google]

But basically the APIs are different but the implementation is the same I guess,

i think it's more accurate to say the APIs are related.

there's a fundamental conflict in unwinder implementations, based on typical use case:

1. for a crash unwinder, you want to be slow and methodical, because the process has already crashed, meaning that you can't really trust anything.
2. for an exception handling unwinder, you want to be fast (because you're still running!), and you should be able to trust that data structures are all intact.

the LLVM unwinder is meant to solve problem 2.

Android's "libunwindstack" solves problem 1.

Android used to use "the libunwind you were thinking of" for problem 1, but it suffered very much from the "you can't please all the people all the time" problem --- it seemed to try to address both use cases, which meant it wasn't great for either. it was actually that experience that convinced us that having two distinct unwinders was the best option for Android. like the old joke, it's really hard to be both a great dessert topping and a great floor wax...

[aronyu79]

I really appreciate the explanations! We are primarily interested in case 1 so would that mean libunwind (non llvm) using execinfo.h is more designed for this?

Again appreciate the info 🙏

[DanAlbert]

We are primarily interested in case 1 so would that mean libunwind (non llvm) using execinfo.h is more designed for this?

You want libunwindstack, as described in #925.

[enh-google]

I really appreciate the explanations! We are primarily interested in case 1 so would that mean libunwind (non llvm) using execinfo.h is more designed for this?

<execinfo.h> on Android is implemented by libunwindstack, so, yes, if you don't need support for < Android T, that's the way to go. (it's also portable to macOS/iOS and glibc.)

if you do need to support older versions of Android, then, yes, you'll want to either build your own [non-LLVM] libunwind or your own libunwindstack. the latter is more safe for crash-dump use cases (and has much better support for Android specifics like unwinding through interpreted/JITed/AOTed Java frames[1]), but the former might be easier to pull in to your project if that's what you're already familiar with.

if you really need the maximum unwinding speed, and only care about native code (for a debug allocator, say), what you actually want is "none of the above" --- enable frame pointers (on by default for arm64) and use something like https://android.googlesource.com/platform/bionic/+/master/libc/bionic/android_unsafe_frame_pointer_chase.cpp instead.

and for anyone who just cares about crashes and only cares about new OS versions... see https://developer.android.com/reference/android/app/ApplicationExitInfo#getTraceInputStream() which lets you get a machine-readable protobuf of your crashes (or consider some of the available middleware that also offers the server-side stuff for collecting/searching/displaying them).

---

1. note that not all of that functionality would be available if you build your own anyway for ART versioning reasons... long term "use <execinfo.h> and let the OS worry about doing the best possible job" is definitely the way to go.