[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

https://github.com/MaskRay closed https://github.com/llvm/llvm-project/pull/103476 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

MaskRay wrote: > Are you able to insert a `.cfi_undefined ` in the generated > assembly? That would tell libunwind to stop unwinding and is cleaner than > this workaround IMO. > > I just noticed a similar problem in FreeBSD's startup files but I plan to fix > those in FreeBSD instead of worki

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

arichardson wrote: Are you able to insert a `.cfi_undefined ` in the generated assembly? That would tell libunwind to stop unwinding and is cleaner than this workaround IMO. I just noticed a similar problem in FreeBSD's startup files but I plan to fix those in FreeBSD instead of working aroun

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

al13n321 wrote: Feel free to close this PR if such change is not going to be accepted. https://github.com/llvm/llvm-project/pull/103476 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

al13n321 wrote: The `clone` syscall, in newly created thread, adjusts stack pointer and stack contents, and there's logically no "caller" stack frame and no return address on the stack. `tools/add-cfi.x86_64.awk` doesn't know about any of that and autogenerates cfi as if it's just normal linea

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

https://github.com/MaskRay requested changes to this pull request. . https://github.com/llvm/llvm-project/pull/103476 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

MaskRay wrote: > This happens with musl libc in __clone(), which has incorrect DWARF unwind > information. Can you elaborate this? How is it incorrect? (tools/add-cfi.x86_64.awk on `musl/src/thread/x86_64/clone.s`, I assume) I guess this workaround does address your issue, but for the upstrea

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

llvmbot wrote: @llvm/pr-subscribers-libunwind Author: Michael Kolupaev (al13n321) Changes If an unwind step leaves both the instruction pointer and the stack pointer unchanged, stop unwinding. Otherwise we'd be stuck in a loop producing the same stack frame over and over. This happens w

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

github-actions[bot] wrote: Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it

[libunwind] [libunwind] Detect cycles of length 1 (PR #103476)

https://github.com/al13n321 created https://github.com/llvm/llvm-project/pull/103476 If an unwind step leaves both the instruction pointer and the stack pointer unchanged, stop unwinding. Otherwise we'd be stuck in a loop producing the same stack frame over and over. This happens with musl li