some questions on libunwind

Hi,

These questions were originally posted on Discord but I have got no reply at all so I am writing this email to post the questions to the developer list.

Background

  1. https://github.com/jemalloc/jemalloc/issues/585

  2. https://reviews.llvm.org/D9744

  3. My team was implementing a database and we planned to add a debug tool for memory profiling when jemalloc is enabled. However, nongnu libunwind caused deadlock from time to time when used together with jeprof.

  4. I am in charge of migrating my team’s toolchain from GCC to LLVM; besides clang, we want to make all of our runtimes (except libc, for the time being) in LLVM, including libcxx, omp, compiler-rt, libunwind

My problems:

  1. libunwind.h is provided in the LLVM repo, but I am curious that why it is not an installation target. Currently, my solution to vendor a LLVM’s header within my team’s repo.

  2. nongnu implementation exposes a specialized unw_init_local2 for stack capturing initiated at signal frame, but this function is not provided at LLVM’s world. According to the test cases in LLVM’s repo, I inferred that LLVM does not need user to specify the signal frame argument. Is this true?

  3. Is there any previous discussion in LLVM side on the deadlock situation of jemalloc and libunwind?

Best wishes.

Hi,

For your first question, the installation target was added last week:

https://github.com/llvm/llvm-project/commit/1c4867e

> 2. nongnu implementation exposes a specialized unw_init_local2 for stack
> capturing initiated at signal frame, but this function is not provided at
> LLVM's world. According to the test cases in LLVM's repo, I inferred that
> LLVM does not need user to specify the signal frame argument. Is this true?

The assumption is that the kernel/libc correctly registers or provides
CFI annotation for the signal frame and that it is therefore
unnecessary.

> 3. Is there any previous discussion in LLVM side on the deadlock situation
> of jemalloc and libunwind?

Make sure that jemalloc locks are unlocked before printing a stack
frame. There really isn't much libunwind can do at this point given that
DSOs can be concurrently loaded or unloaded all the time.

Joerg

Thanks so much for your answers and suggestions! There is no much comment in libunwind’s header. Maybe it would be better to state some assumptions and explanations in the src comments or associated docs?