Schrodinger ZHU Yifan via llvm-dev
2021-Dec-20 04:36 UTC
[llvm-dev] 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. Schrodinger ZHU Yifan School of Data Science, CUHK(SZ) Website: https://github.com/schrodingerzhu Github: SchrodingerZhu Twitter: ZhuSchrodinger Sent with ProtonMail Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211220/26314e79/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - i at zhuyi.fan - 0xE405E45C.asc Type: application/pgp-keys Size: 3237 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211220/26314e79/attachment.key> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211220/26314e79/attachment.sig>
Hi, For your first question, the installation target was added last week: https://github.com/llvm/llvm-project/commit/1c4867e On Mon, Dec 20, 2021 at 12:37 PM Schrodinger ZHU Yifan via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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. > > Schrodinger ZHU Yifan > School of Data Science, CUHK(SZ) > *Website: https://github.com/schrodingerzhu > <https://github.com/schrodingerzhu>* > *Github:* SchrodingerZhu > *Twitter:* ZhuSchrodinger > > Sent with ProtonMail <https://protonmail.com/> Secure Email. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211220/ac07fdbb/attachment.html>