llvm-project.git/llvm/lib/Support/CrashRecoveryContext.cpp, branch users/nico/python-1

[llvm] Remove unused includes (NFC) (#142733)

2025-06-04T19:30:52+00:00

These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.

Reland: [llvm][clang] Allocate a new stack instead of spawning a new thread to get more stack space (#136046)

2025-05-01T02:14:15+00:00

Reland https://github.com/llvm/llvm-project/pull/133173

Clang spawns a new thread to avoid running out of stack space. This can
make debugging and performance analysis more difficult as how the
threads are connected is difficult to recover.

This patch introduces `runOnNewStack` and applies it in Clang. On
platforms that have good support for it this allocates a new stack and
moves to it using assembly. Doing split stacks like this actually runs
on most platforms, but many debuggers and unwinders reject the large or
backwards stack offsets that occur. Apple platforms and tools are known
to support this, so this only enables it there for now.

Revert "[llvm][clang] Allocate a new stack instead of spawning a new … (#135865)

2025-04-15T21:46:55+00:00

…thread to get more stack space (#133173)"

This change breaks the Clang build on Mac AArch64.

This reverts commit d0c973a7a0149db3b71767d4c5a20a31e6a8ed5b. This
reverts commit 429a84f8a4bf559f43f50072747ef49d3e3b2cf1. This reverts
commit 4f64c80d5a23c244f942193e58ecac666c173308.

[llvm][clang] Allocate a new stack instead of spawning a new thread to get more stack space (#133173)

2025-04-15T18:19:07+00:00

Clang spawns a new thread to avoid running out of stack space. This can
make debugging and performance analysis more difficult as how the
threads are connected is difficult to recover.

This patch introduces `runOnNewStack` and applies it in Clang. On
platforms that have good support for it this allocates a new stack and
moves to it using assembly. Doing split stacks like this actually runs
on most platforms, but many debuggers and unwinders reject the large or
backwards stack offsets that occur. Apple platforms and tools are known
to support this, so this only enables it there for now.

[Support] Clarify CrashRecoveryContext exception codes on Windows. NFC

2023-02-08T23:03:58+00:00

Differential revision: https://reviews.llvm.org/D143609

[llvm] Refactor leftover ThreadLocal usage in MinGW code

2023-01-11T20:47:25+00:00

This code was accidently left over after https://reviews.llvm.org/D141349 and now leads to compilation failure due to missing declaration (since the class has been removed)

Just migrate it by making use of `LLVM_THREAD_LOCAL` instead.

Differential Revision: https://reviews.llvm.org/D141535

Remove the ThreadLocal template from LLVM.

2023-01-11T04:07:52+00:00

This has been obsoleted by C++ thread_local for a long time.
As far as I know, Xcode was the last supported toolchain to add
support for C++ thread_local in 2016.

As a precaution, use LLVM_THREAD_LOCAL which provides even greater
backwards compatibility, allowing this to function even pre-C++11
versions of GCC.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D141349

Revert "Remove the ThreadLocal template from LLVM."

2023-01-10T04:21:38+00:00

This reverts commit 54d78b639b9c18b42abd4fac5c6e76105f06b3ef.

Revert "Fix warning when building with GCC."

2023-01-10T04:21:29+00:00

This reverts commit 971786254cc4093eb1c56625b8da0fd3544f6512.

Fix warning when building with GCC.

2023-01-10T04:19:17+00:00