aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/CrashRecoveryContext.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-06-04[llvm] Remove unused includes (NFC) (#142733)Kazu Hirata1-1/+0
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.
2025-04-30Reland: [llvm][clang] Allocate a new stack instead of spawning a new thread ↵Michael Spencer1-0/+11
to get more stack space (#136046) 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.
2025-04-15Revert "[llvm][clang] Allocate a new stack instead of spawning a new … ↵Daniel Thornburgh1-11/+0
(#135865) …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.
2025-04-15[llvm][clang] Allocate a new stack instead of spawning a new thread to get ↵Michael Spencer1-0/+11
more stack space (#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.
2023-02-08[Support] Clarify CrashRecoveryContext exception codes on Windows. NFCAlexandre Ganea1-5/+8
Differential revision: https://reviews.llvm.org/D143609
2023-01-11[llvm] Refactor leftover ThreadLocal usage in MinGW codeMarkus Böck1-4/+4
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
2023-01-10Remove the ThreadLocal template from LLVM.Owen Anderson1-22/+15
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
2023-01-09Revert "Remove the ThreadLocal template from LLVM."Owen Anderson1-14/+22
This reverts commit 54d78b639b9c18b42abd4fac5c6e76105f06b3ef.
2023-01-09Revert "Fix warning when building with GCC."Owen Anderson1-2/+2
This reverts commit 971786254cc4093eb1c56625b8da0fd3544f6512.
2023-01-09Fix warning when building with GCC.Owen Anderson1-2/+2
2023-01-09Remove the ThreadLocal template from LLVM.Owen Anderson1-22/+14
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: majnemer Differential Revision: https://reviews.llvm.org/D141347
2022-12-16[Support] llvm::Optional => std::optionalFangrui Song1-1/+1
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02[llvm] Use std::nullopt instead of None (NFC)Kazu Hirata1-1/+1
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-09-08[llvm] Use std::size instead of llvm::array_lengthofJoe Loser1-1/+1
LLVM contains a helpful function for getting the size of a C-style array: `llvm::array_lengthof`. This is useful prior to C++17, but not as helpful for C++17 or later: `std::size` already has support for C-style arrays. Change call sites to use `std::size` instead. Differential Revision: https://reviews.llvm.org/D133429
2022-08-03ManagedStatic: remove from CrashRecoveryContextNicolai Hähnle1-21/+29
Differential Revision: https://reviews.llvm.org/D129126
2022-04-27[Support] Factor out isCrash from throwIfCrashAlexander Shaposhnikov1-2/+11
This diff factors out the check "isCrash" from the static method "throwIfCrash". This is a helper function that can be useful in debugging / analysis, in particular, I'm planning to use it in the future patches for lld-fuzzer. Test plan: 1/ ninja check-all 2/ export LLD_IN_TEST=5 ninja check-lld Differential revision: https://reviews.llvm.org/D124414
2022-03-11Cleanup include: TableGenserge-sans-paille1-4/+1
This also includes a few cleanup from Support. Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121331
2022-02-06[llvm] Use = default (NFC)Kazu Hirata1-1/+1
2022-01-26Revert "Rename llvm::array_lengthof into llvm::size to match std::size from ↵Benjamin Kramer1-1/+1
C++17" This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2. - It conflicts with the existing llvm::size in STLExtras, which will now never be called. - Calling it without llvm:: breaks C++17 compat
2022-01-26Rename llvm::array_lengthof into llvm::size to match std::size from C++17serge-sans-paille1-1/+1
As a conquence move llvm::array_lengthof from STLExtras.h to STLForwardCompat.h (which is included by STLExtras.h so no build breakage expected).
2022-01-26[NFC] Additional header dependency cleanup LLVMSupportserge-sans-paille1-1/+4
A few more forward-declarations, a few less headers. the impact on number of preprocessed lines for LLVMSupport is negligible (-3K lines) but it's always good to remove dependencies. Related discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup
2021-07-28[llvm] Replace LLVM_ATTRIBUTE_NORETURN with C++11 [[noreturn]]Fangrui Song1-2/+1
[[noreturn]] can be used since Oct 2016 when the minimum compiler requirement was bumped to GCC 4.8/MSVC 2015. Note: the definition of LLVM_ATTRIBUTE_NORETURN is kept for now.
2021-07-08Recommit: Support: add llvm::thread class that supports specifying stack size.Tim Northover1-4/+7
This adds a new llvm::thread class with the same interface as std::thread except there is an extra constructor that allows us to set the new thread's stack size. On Darwin even the default size is boosted to 8MB to match the main thread. It also switches all users of the older C-style `llvm_execute_on_thread` API family over to `llvm::thread` followed by either a `detach` or `join` call and removes the old API. Moved definition of DefaultStackSize into the .cpp file to hopefully fix the build on some (GCC-6?) machines.
2021-07-08Revert "Support: add llvm::thread class that supports specifying stack size."Tim Northover1-7/+4
It's causing build failures because DefaultStackSize isn't defined everywhere it should be and I need time to investigate.
2021-07-08Support: add llvm::thread class that supports specifying stack size.Tim Northover1-4/+7
This adds a new llvm::thread class with the same interface as std::thread except there is an extra constructor that allows us to set the new thread's stack size. On Darwin even the default size is boosted to 8MB to match the main thread. It also switches all users of the older C-style `llvm_execute_on_thread` API family over to `llvm::thread` followed by either a `detach` or `join` call and removes the old API.
2021-02-10Revert "Make gCrashRecoveryEnabled thread local"Jacques Pienaar1-1/+5
This reverts commit 5e77ea04f214c7a18bd5c782c8b8a7b7c828ad7a. Causes a breakage on Windows buildbot.
2021-02-10Make gCrashRecoveryEnabled thread localJacques Pienaar1-5/+1
If context is enabled/disabled and queried concurrently then this results in a data race/TSAN failure with RunSafely (where boolean variable was not locked). There doesn't seem to be a reasonable way to enable threads that enable and disable recovery in parallel (without also keeping gCrashRecoveryEnabled's lock held during Fn execution which seems undesirable). This makes enable checking if enabled thread local and consistent with other thread local usage of crash context here. Differential Revision: https://reviews.llvm.org/D93907
2021-01-28[Support] Add some missing namespace closure comments. NFCI.Simon Pilgrim1-2/+2
Fixes some clang-tidy warnings.
2020-11-12[LLD] Fix include following 45b8a741fbbf271e0fb71294cb7cdce3ad4b9bf3Alexandre Ganea1-0/+1
2020-11-12[LLD][COFF] When using LLD-as-a-library, always prevent re-entrance on failuresAlexandre Ganea1-0/+20
This is a follow-up for D70378 (Cover usage of LLD as a library). While debugging an intermittent failure on a bot, I recalled this scenario which causes the issue: 1.When executing lld/test/ELF/invalid/symtab-sh-info.s L45, we reach lld::elf::Obj-File::ObjFile() which goes straight into its base ELFFileBase(), then ELFFileBase::init(). 2.At that point fatal() is thrown in lld/ELF/InputFiles.cpp L381, leaving a half-initialized ObjFile instance. 3.We then end up in lld::exitLld() and since we are running with LLD_IN_TEST, we hapily restore the control flow to CrashRecoveryContext::RunSafely() then back in lld::safeLldMain(). 4.Before this patch, we called errorHandler().reset() just after, and this attempted to reset the associated SpecificAlloc<ObjFile<ELF64LE>>. That tried to free the half-initialized ObjFile instance, and more precisely its ObjFile::dwarf member. Sometimes that worked, sometimes it failed and was catched by the CrashRecoveryContext. This scenario was the reason we called errorHandler().reset() through a CrashRecoveryContext. But in some rare cases, the above repro somehow corrupted the heap, creating a stack overflow. When the CrashRecoveryContext's filter (that is, __except (ExceptionFilter(GetExceptionInformation()))) tried to handle the exception, it crashed again since the stack was exhausted -- and that took the whole application down. That is the issue seen on the bot. Locally it happens about 1 times out of 15. Now this situation can happen anywhere in LLD. Since catching stack overflows is not a reliable scenario ATM when using CrashRecoveryContext, we're now preventing further re-entrance when such failures occur, by signaling lld::SafeReturn::canRunAgain=false. When running with LLD_IN_TEST=2 (or above), only one iteration will be executed, instead of two. Differential Revision: https://reviews.llvm.org/D88348
2020-09-24[Support] On Unix, let the CrashRecoveryContext return the signal codeAlexandre Ganea1-3/+4
Before this patch, the CrashRecoveryContext was returning -2 upon a signal, like ExecuteAndWait does. This didn't match the behavior on Windows, where the the exception code was returned. We now return the signal's code, which optionally allows for re-throwing the signal later. Doing so requires all custom handlers to be removed first, through llvm::sys::unregisterHandlers() which we made a public API. This is part of https://reviews.llvm.org/D70378
2020-09-24[Support] On Windows, ensure abort() can be catched several times in a row ↵Alexandre Ganea1-0/+7
with CrashRecoveryContext Before this patch, the CrashRecoveryContext would only catch the first abort(). Any further calls to abort() inside subsquent CrashRecoveryContexts would not be catched. This is because the Windows CRT removes the abort() handler before calling it. This is part of https://reviews.llvm.org/D70378
2020-08-26[SystemZ/ZOS] Add header file to encapsulate use of <sysexits.h>Kai Nacke1-3/+1
The non-standard header file `<sysexits.h>` provides some return values. `EX_IOERR` is used to as a special value to signal a broken pipe to the clang driver. On z/OS Unix System Services, this header file does not exists. This patch - adds a check for `<sysexits.h>`, removing the dependency on `LLVM_ON_UNIX` - adds a new header file `llvm/Support/ExitCodes`, which either includes `<sysexits.h>` or defines `EX_IOERR` - updates the users of `EX_IOERR` to include the new header file Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D83472
2020-02-28llvm-ar: Fix MinGW compilationHans Wennborg1-1/+1
llvm-ar is using CompareStringOrdinal which is available only starting with Windows Vista (WINVER 0x600). Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar. Patch by Cristian Adam! Differential revision: https://reviews.llvm.org/D74599
2020-02-11Fix MSVC build with C++ EH enabledReid Kleckner1-1/+1
Mark the CrashRecoveryContextImpl constructor noexcept, so that MSVC won't emit an unwind helper to clean up the allocation from `new` if the constructor throws an exception. Otherwise, MSVC complains: llvm\lib\Support\CrashRecoveryContext.cpp(220): error C2712: \ Cannot use __try in functions that require object unwinding The other simple fix would be to wrap `new` in a static helper or lambda. Users have reported that Tensorflow builds LLVM with /EHsc.
2020-02-11[Clang][Driver] After default -fintegrated-cc1, make ↵Alexandre Ganea1-5/+25
llvm::report_fatal_error() generate preprocessed source + reproducer.sh again. Added a test for #pragma clang __debug llvm_fatal_error to test for the original issue. Added llvm::sys::Process::Exit() and replaced ::exit() in places where it was appropriate. This new function would call the current CrashRecoveryContext if one is running on the same thread; or call ::exit() otherwise. Fixes PR44705. Differential Revision: https://reviews.llvm.org/D73742
2020-02-06[Support] When using SEH, create a impl instance for CrashRecoveryContext. NFCI.Alexandre Ganea1-25/+35
Previously, the SEH codepath in CrashRecoveryContext didn't create a CrashRecoveryContextImpl. The other codepaths (VEH and Unix) were creating it. When running with -fintegrated-cc1, this is needed to handle exit() as a jump to CrashRecoveryContext's exception filter, through a call to RaiseException. In that situation, we need a user-defined exception code, which is later interpreted as an exit() by the exception filter. This in turn needs to set RetCode accordingly, *inside* the exception filter, and *before* calling HandleCrash(). Differential Revision: https://reviews.llvm.org/D74078
2020-02-06[Clang] Remove unused #pragma clang __debug handle_crashAlexandre Ganea1-8/+0
As discussed in D70568, remove this because it isn't used anywhere, and I think it's better to go through real crashes for testing (#pragma clang __debug crash). Also remove the support function llvm::CrashRecoveryContext::HandleCrash() which was added at the same time by @ddunbar. Differential Revision: https://reviews.llvm.org/D74063
2020-01-29Work around PR44697 in CrashRecoveryContextHans Wennborg1-0/+7
2020-01-12[NFC] Fix compilation of CrashRecoveryContext.cpp on mingwMarkus Böck1-1/+2
Patch by Markus Böck. Differential Revision: https://reviews.llvm.org/D72564
2020-01-11[Support] Optionally call signal handlers when a function wrapped by the the ↵Alexandre Ganea1-13/+52
CrashRecoveryContext fails This patch allows for handling a failure inside a CrashRecoveryContext in the same way as the global exception/signal handler. A failure will have the same side-effect, such as cleanup of temporarty file, printing callstack, calling relevant signal handlers, and finally returning an exception code. This is an optional feature, disabled by default. This is a support patch for D69825. Differential Revision: https://reviews.llvm.org/D70568
2019-11-13Revert "Forward declare Optional<T> in STLExtras.h"Reid Kleckner1-1/+0
This reverts commit a36f316390d4bc1bcb0e9de0f55831385ab24099. I did not intend to push this with the InitializePasses.h change.
2019-11-13Forward declare Optional<T> in STLExtras.hReid Kleckner1-0/+1
WIP stats
2019-10-28minor doc typo fix / testing github commitRafael Stahl1-1/+1
2019-10-23Reland "[Support] Add a way to run a function on a detached thread""Sam McCall1-1/+4
This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237. The immediate callers have been fixed to pass nullopt where appropriate.
2019-08-19[Support] Replace sys::Mutex with their standard equivalents.Benjamin Kramer1-4/+4
Only use a recursive mutex if it can be locked recursively. llvm-svn: 369295
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-07-30Remove trailing spaceFangrui Song1-2/+2
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
2018-05-01Remove \brief commands from doxygen comments.Adrian Prantl1-1/+1
We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-04-30IWYU for llvm-config.h in llvm, additions.Nico Weber1-1/+1
See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
generated by cgit v1.1 at 2025-09-29 08:48:45 +0000