In D90898#2496725, @compnerd wrote:

In D90898#2384775, @rprichard wrote:

In D90898#2379387, @compnerd wrote:

Could you add a bit of a comment explaining why the XOM case is not protected against?

I think I can expand on the comment.

libunwind can be used for generating backtraces during regular execution (e.g. profiling) and crashing if the XOM is in use seems unfortunate.

For profiling, I assume the unwind info needs to be accurate at every instruction? I know that's definitely not the case for AArch64, but I thought it's still only mostly-accurate on other archs? I don't *really* know that unwinding through a signal handler is important for Android, but I don't know how to rule it out either, and we do have a test for it. I think the test predated Android's libunwindstack unwinder. Maybe someone could be using _Unwind_Backtrace in a segfault handler, and that probably avoids the async-unwind-info problem most of the time. But I also don't think that's how third-party Android crash dumpers work.

Sure, though, libunwind is generic and is used outside of android as well, including other AArch64 targets, so we do need to consider those use cases while making changes.

Can I get a code-owner to review this?

Enable unwind_leaffunction.pass.cpp for AArch64 Linux.

Rename flag to COMPILER_RT_BUILTINS_HIDE_SYMBOLS.

I also think this is a good change.

I'm using this change in https://android-review.googlesource.com/c/toolchain/llvm_android/+/1532841.

It looks OK to me.

Keep exporting these symbols on Android for compatibility.

I assume the LIBUNWIND_HERMETIC_STATIC_LIBRARY setting isn't used on Darwin -- it leaves unw_* symbols as Extern and not PrivateExtern. Maybe the CMake file could reject that flag on Darwin instead of trying to make it work.

Fix LIBUNWIND_HERMETIC_STATIC_LIBRARY on macOS.

That could work. Some similar approaches:

• process_vm_readv
• pipe+write
• open /proc/self/mem

Update comments.

Add +/- to __compiler_rt_scalbnX comment.

Rename new fmax/scalbn fp_lib.h params from a/b to x/y for consistency with the new tests and with the existing __compiler_rt_logb*.

Remove obsoleted crt_fmax[f] and crt_scalbn[f] functions.

The __compiler_rt_{logb,scalbn,fmax}* functions don't work with x87 extended-precision FP, and I think FPUtil would handle that. Perhaps the existing inline functions could be extended to support x87, though.

The existing __compiler_rt_logb* inline functions were also added to address PR32279, in D49514. On Android, all of fmax*/logb*/scalbn* are in libm, not libc. I commented more on the bug: https://bugs.llvm.org/show_bug.cgi?id=32279#c7.

Switch scalbn calls in ppc/divtc3.c to __compiler_rt_scalbn. I verified that, after doing so, libclang_rt.builtins-powerpc64le.a has no unresolved symbols for fmax*/logb*/scalbn*.

With this change, I think PR32279 is still an issue with non-standard FP formats, like the x86 80-bit extended-precision format. In principle, it seems straightforward to extend the __compiler_rt_* inline functions to handle that format.

In D90898#2379387, @compnerd wrote:

Could you add a bit of a comment explaining why the XOM case is not protected against?

Thanks for the review. It looks like I still need someone from the libunwind group to accept it, though.

Thanks for the review. It looks like I still need someone from the libunwind group to accept it, though.

I uploaded the Android benchmark I used: https://gist.github.com/rprichard/1688de36f0132a40294adb0409189533.

This change enables the FrameHeaderCache for EHABI.

Apply clang-format fix.

I think these libunwind tests are relying on the signal trampoline having "good enough" unwind info, but AFAIK, that's not the case with the signal trampoline (__kernel_rt_sigreturn) in the AArch64 Linux vDSO. There was a commit recently adjusting .cfi_startproc to let the unwinder find the vDSO's FDE, but then this was quickly reverted. The FDE change allowed libgcc to find the FDE, and that broke glibc pthread cancellation somehow, so the FDE was then removed:

• https://github.com/torvalds/linux/commit/a4eb355a3fdad85d16e4b098e8d56bb28b812ce0
• https://github.com/torvalds/linux/commit/87676cfca14171fc4c99d96ae2f3e87780488ac4

Abandoned in favor of D87750.

This seems like a bad name.

Rename dso_length to text_segment_length.

Adding @saugustine -- this patch makes the frame header cache one word larger per entry.

Stylistic change.

I uploaded D87750, an alternative to this patch.

An alternative to D86256.

Just want to comment "Or use LLD, which automatically inserts the terminator" - the zero terminator CIE is to work around a glibc issue D46566

In D86256#2270331, @mstorsjo wrote:

The commit description talks about making the caching optional, but I don't really see that aspect in the patch - or maybe I'm just not studying it closely enough?

I think I'm fine with this revision. I was wondering if the two functions should be removed from the GNU libsupc++'s cxxabi.h as well, which also declares both of the functions with an int return type. (i.e. It has the same issue as LLVM's cxxabi.h.)

Use -1 to indicate "search all cache entries".

In D86748#2262437, @compnerd wrote:

Why not use -1 as the indicator instead of 0?

The Linux ABI Extensions spec describes the binary search table of .eh_frame_hdr as optional, so maybe falling back to .eh_frame scanning could be necessary to accommodate some ELF files? I wonder what situation results in an omitted search table. ld.bfd does have code for outputting .eh_frame_hdr without a search table.

On second thought, maybe I don't actually need this change, and the includes still seem like a mess in libunwind. Maybe it makes more sense to do a larger revision eventually.

In D86768#2253572, @saugustine wrote:

I am going to accept this, since no one else seems to be able to review it. But the problem here is that no one really knows what a simplified ifdef chain with the same functionality looks like. I tried a couple of times and failed miserably.

So if this works, great! If not, we will need to revert it quickly.

Do I need an approval from a libunwind group member?

Remove most of the previous change. Add a comment about Apple/armv7k.

In D86767#2244767, @steven_wu wrote:

Sorry for the inconvenience that libunwind is not really buildable for armv7 from iOS SDK. You can build a single threaded version without referring to those interfaces. If this is really troublesome for you, feel free to file a bug report and we can see what can be done here.

If the unwinder uses dl_iterate_phdr, then entries that are automatically added to DwarfFDECache would become invalid if the module containing the entry were unloaded. (On Apple systems, DwarfFDECache registers dyldUnloadHook to remove unloaded entries.)

FWIW, when compact unwinding defers to DWARF (compactSaysUseDwarf), the unwinder begins a scan of .eh_frame at a given offset. Is that really the right behavior, or will the offset always point directly at the appropriate FDE (as with the DWARF index .eh_frame_hdr)?

FWIW, I compiled libunwind for Darwin, and I had trouble getting it to compile for armv7. Unwind-sjlj.c needs these things:

• #include <System/pthread_machdep.h>
• _pthread_getspecific_direct(__PTK_LIBC_DYLD_Unwind_SjLj_Key)

Rebase this change.

Split out the chain-of-ifdefs change into D86768.

In D86372#2234459, @rprichard wrote:

In D86372#2234249, @hans wrote:

From the discussion on D86254, this should be cherry-picked to 11.x right?

Correct. This findUnwindSectionsByPhdr change (D86372) is needed for 11.

In D86411#2233326, @mstorsjo wrote:

Oh, ok, I see - maybe CMake deduced that the option wasn't needed in my case, when building with a compiler that defaults to a new enough version.