summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows/Signals.inc
Commit message (Collapse)AuthorAgeFilesLines
* llvm-ar: Fix MinGW compilationHans Wennborg2020-02-281-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 (cherry picked from commit 01f9abbb50b11dd26b9ccb7cb565cc955d2b9c74) This is for https://bugs.llvm.org/show_bug.cgi?id=44907
* [Support] Don't modify the current EH context during stack unwindingReid Kleckner2020-02-111-1/+7
| | | | | | | | | | | | | Copy it instead. Otherwise, key registers (such as RBP) may get zeroed out by the stack unwinder. Fixes CrashRecoveryTest.DumpStackCleanup with MSVC in release builds. Reviewed By: stella.stamenova Differential Revision: https://reviews.llvm.org/D73809 (cherry picked from commit b074acb82f7e75a189fa7933b09627241b166121)
* [Support] Optionally call signal handlers when a function wrapped by the the ↵Alexandre Ganea2020-01-111-40/+17
| | | | | | | | | 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
* [Signal] Allow llvm clients to opt into one-shot SIGPIPE handlingVedant Kumar2019-11-181-0/+7
| | | | | | | | | | | | | | | | | | | | Allow clients of the llvm library to opt-in to one-shot SIGPIPE handling, instead of forcing them to undo llvm's SIGPIPE handler registration (which is brittle). The current behavior is preserved for all llvm-derived tools (except lldb) by means of a default-`true` flag in the InitLLVM constructor. This prevents "IO error" crashes in long-lived processes (lldb is the motivating example) which both a) load llvm as a dynamic library and b) *really* need to ignore SIGPIPE. As llvm signal handlers can be installed when calling into libclang (say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the current model. Differential Revision: https://reviews.llvm.org/D70277
* Revert "Disable exit-on-SIGPIPE in lldb"Vedant Kumar2019-10-241-3/+0
| | | | | | | This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30. In post-commit review, Pavel pointed out that there's a simpler way to ignore SIGPIPE in lldb that doesn't rely on llvm's handlers.
* Disable exit-on-SIGPIPE in lldbVedant Kumar2019-10-181-0/+3
| | | | | | | | | | | | | | | | | | Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
* Support for dumping current PrettyStackTrace on SIGINFO (Ctrl-T)Jordan Rose2019-07-121-0/+4
| | | | | | | | | | | | | | | | | | | | Support SIGINFO (and SIGUSR1 for POSIX purposes) to tell what long-running jobs are doing, as inspired by BSD tools (including on macOS), by dumping the current PrettyStackTrace. This adds a new kind of signal handler for non-fatal "info" signals, similar to the "interrupt" handler that already exists for SIGINT (Ctrl-C). It then uses that handler to update a "generation count" managed by the PrettyStackTrace infrastructure, which is then checked whenever a PrettyStackTraceEntry is pushed or popped on each thread. If the generation has changed---i.e. if the user has pressed Ctrl-T---the stack trace is dumped, though unfortunately it can't include the deepest entry because that one is currently being constructed/destructed. https://reviews.llvm.org/D63750 llvm-svn: 365911
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-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
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-011-0/+1
| | | | | | | | | | | | | | | | | | The idea behind WindowsSupport.h is that it's in the source directory so that windows.h'isms don't leak out into the larger LLVM project. To that end, any symbol that references a symbol from windows.h must be in this private header, and not in a public header. However, we had some useful utility functions in WindowsSupport.h which have no dependency on the Windows API, but still only make sense on Windows. Those functions should be usable outside of Support since there is no risk of causing a windows.h leak. Although this introduces some preprocessor logic in some header files, It's not too egregious and it's better than the alternative of duplicating a ton of code. Differential Revision: https://reviews.llvm.org/D47662 llvm-svn: 333798
* Signal handling should be signal-safeJF Bastien2018-05-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. Fix r332428 which I reverted in r332429. I originally used double-wide CAS because I was lazy, but some platforms use a runtime function for that which thankfully failed to link (it would have been bad for signal handlers otherwise). I use a separate flag to guard the data instead. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: steven_wu, llvm-commits llvm-svn: 332496
* Revert "Signal handling should be signal-safe"JF Bastien2018-05-161-3/+2
| | | | | | Some bots don't have double-pointer width compare-and-exchange. Revert for now.q llvm-svn: 332429
* Signal handling should be signal-safeJF Bastien2018-05-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46858 llvm-svn: 332428
* [NFC] Update commentsJF Bastien2018-05-151-11/+11
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-4/+4
| | | | | | | | | | | | | | | | 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
* [Support] Fix building for Windows on ARMMartin Storsjo2018-04-131-1/+9
| | | | | | | | | | | The commit in SVN r310001 that added support for this actually didn't use the right struct field for the frame pointer - for ARM, there is no register named Fp in the CONTEXT struct. On Windows, the R11 register is used as frame pointer. Differential Revision: https://reviews.llvm.org/D45590 llvm-svn: 329991
* Remove HAVE_LIBPSAPI, HAVE_SHELL32.Nico Weber2018-04-021-3/+0
| | | | | | | | | | These used to be set in the old autoconf build, but the cmake build has had a "TODO: actually check for these" comment since it was checked in, and they were set to 1 on mingw unconditionally. It seems safe to say that they always exist under mingw, so just remove them and assume they're set exactly when on mingw (with msvc, we use `pragma comment` instead of linking these via flags). llvm-svn: 328992
* Typo fix SIBABRT -> SIGABRT.Eric Christopher2018-01-181-1/+1
| | | | | | Based on a patch by Henry Wong! llvm-svn: 322902
* Support: WOA64 and WOA SignalsMartell Malone2017-08-031-6/+23
| | | | | | | | Reviewers: rnk Differential Revision: https://reviews.llvm.org/D21813 llvm-svn: 310001
* Remove name space pollution from Signals.cppKristof Beyls2017-03-311-1/+1
| | | | llvm-svn: 299224
* Add missing includes on Windows.Zachary Turner2016-12-211-0/+1
| | | | | | | Patch by Andrey Khalyavin Differential Revision: https://reviews.llvm.org/D27915 llvm-svn: 290263
* Blind attempt to fix windows build after r283290 - Use StringRef in ↵Mehdi Amini2016-10-051-1/+1
| | | | | | StringSaver API (NFC) llvm-svn: 283294
* Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer2016-08-121-1/+1
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
* Explicitly specify the ANSI version of these Win32 APIs. While these are ↵Aaron Ballman2016-06-231-3/+3
| | | | | | seemingly unrelated changes, they are all NFC because we currently default to the ANSI versions of the APIs when building for Windows. This simply makes the ANSI usage explicit. llvm-svn: 273564
* Search for llvm-symbolizer binary in the same directory as argv[0], beforeRichard Smith2016-06-091-2/+7
| | | | | | | looking for it along $PATH. This allows installs of LLVM tools outside of $PATH to find the symbolizer and produce pretty backtraces if they crash. llvm-svn: 272232
* [Support] Creation of minidump after compiler crash on WindowsLeny Kholodov2016-05-041-1/+216
| | | | | | | | | | | In the current implementation compiler only prints stack trace to console after crash. This patch adds saving of minidump files which contain a useful subset of the information for further debugging. Differential Revision: http://reviews.llvm.org/D18216 llvm-svn: 268519
* Revert r130657, "Windows/DynamicLibrary.inc: Clean up ELM_Callback. We may ↵NAKAMURA Takumi2016-03-071-1/+1
| | | | | | | | check the decl instead of the versions of individual libraries." We may assume the type of 1st argument as PCSTR in PENUMLOADED_MODULES_CALLBACK. PSTR was in the ancient mingw32. llvm-svn: 262810
* Revert "[Windows] Simplify assertion code. NFC."Reid Kleckner2016-01-111-1/+4
| | | | | | | | | | | | | This reverts commit r254363. load64BitDebugHelp() has the side effect of loading dbghelp and setting globals. It should be called in no-asserts builds as well as debug builds. llvm_unreachable is also not appropriate here, since we actually want to return if dbghelp couldn't be loaded in a non-asserts build. llvm-svn: 257384
* [Windows] Simplify assertion code. NFC.Davide Italiano2015-12-011-4/+1
| | | | llvm-svn: 254363
* Fix a signed/unsigned mismatch warning; NFC.Aaron Ballman2015-11-051-1/+1
| | | | llvm-svn: 252164
* [Windows] Symbolize with llvm-symbolizer instead of dbghelp in a self-hostReid Kleckner2015-11-051-9/+102
| | | | | | | | | | | | | | | | Summary: llvm-symbolizer understands both PDBs and DWARF, so it is more likely to succeed at symbolization. If llvm-symbolizer is unavailable, we will fall back to dbghelp. This also makes our crash traces more similar between Windows and Linux. Reviewers: Bigcheese, zturner, chapuni Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12884 llvm-svn: 252118
* Rename RunCallBacksToRun to llvm::sys::RunSignalHandlersYaron Keren2015-07-221-1/+1
| | | | | | | | | | | | And expose it in Signals.h, allowing clients to call it directly, possibly LLVMErrorHandler which currently calls RunInterruptHandlers but not RunSignalHandlers, thus for example not printing the stack backtrace on Unixish OSes. On Windows it does happen because RunInterruptHandlers ends up calling the callbacks as well via Cleanup(). This difference in behaviour and code structures in */Signals.inc should be patched in the future. llvm-svn: 242936
* De-duplicate Unix & Windows CallBacksToRunYaron Keren2015-07-221-10/+3
| | | | | | | | | Move CallBacksToRun into the common Signals.cpp, create RunCallBacksToRun() and use these in both Unix/Signals.inc and Windows/Signals.inc. Lots of potential code to be merged here. llvm-svn: 242925
* [Support] Lazy load of dbghlp.dll on WindowsLeny Kholodov2015-07-021-30/+33
| | | | | | | | | | | | | This patch changes linkage with dbghlp.dll for clang from static (at load time) to on demand (at the first use of required functions). Clang uses dbghlp.dll only in minor use-cases. First of all in case of crash and in case of plugin load. The dbghlp.dll library can be absent on system. In this case clang will fail to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll is not available. Differential Revision: http://reviews.llvm.org/D10737 llvm-svn: 241271
* Rangify for loop in Cleanup(), NFC.Yaron Keren2015-05-191-2/+2
| | | | llvm-svn: 237695
* Prevent Cleanup() from running more than once.Yaron Keren2015-05-191-0/+3
| | | | llvm-svn: 237694
* Use the cleaner syntx value initialization to zero initialize POD structs.Yaron Keren2015-04-241-6/+3
| | | | | | Suggestion from David Blaikie! llvm-svn: 235721
* Silence clang warning: missing field 'Dr0' initializer.Yaron Keren2015-04-241-1/+2
| | | | llvm-svn: 235719
* Remove FilesToRemove->push_back(Filename) from sys::DontRemoveFileOnSignal.Yaron Keren2015-04-211-1/+0
| | | | llvm-svn: 235408
* Add boolean to PrintStackTraceOnErrorSignal to disable crash reporting.Pete Cooper2015-04-071-1/+1
| | | | | | | | | | | | | | | | | | | The current crash reporting on Mac OS is only disabled via an environment variable. This adds a boolean (default false) which can also disable crash reporting. The only client right now is the unittests which don't ever want crash reporting, but do want to detect killed programs. Reduces the time to run the APFloat unittests on my machine from [----------] 47 tests from APFloatTest (51250 ms total) to [----------] 47 tests from APFloatTest (765 ms total) Reviewed by Reid Kleckner and Justin Bogner llvm-svn: 234353
* Sometimes report_fatal_error is called when there is not a handler function ↵Aaron Ballman2015-03-261-3/+17
| | | | | | used to fail gracefully. In that case, RunInterruptHandlers is called, which attempts to enter a critical section object. Ensure that the critical section is properly initialized so that this code functions properly, and tools like clang-tidy do not crash in Debug builds. llvm-svn: 233282
* No need to prototype RtlCaptureContext with mingw-w64.Yaron Keren2015-03-141-2/+3
| | | | llvm-svn: 232269
* Wrap in __MINGW32__ to avoid warnings from msvc.Benjamin Kramer2015-03-111-1/+3
| | | | llvm-svn: 231933
* Add missing namespace specifier for MSVC.Benjamin Kramer2015-03-111-1/+1
| | | | llvm-svn: 231930
* RtlCaptureContext is absent from the mingw32 headers, provide a prototype.Benjamin Kramer2015-03-111-1/+4
| | | | llvm-svn: 231929
* Replace PrintStackTrace(FILE*) with PrintStackTrace(raw_ostream&)Zachary Turner2015-03-051-15/+20
| | | | | | | | | | This will be followed by a change on the clang side to update the only user of this function with the new version. Differential Revision: http://reviews.llvm.org/D8074 Reviewed By: Reid Kleckner llvm-svn: 231392
* Silence -Wmissing-braces warning from clang-clReid Kleckner2015-03-051-1/+1
| | | | | | | | The first element of STACKFRAME64 is a struct and Clang wants us to put braces around it's initialization. Instead, drop the zero. The result should be the same. llvm-svn: 231387
* [Windows] Implement PrintStackTrace(FILE*)Zachary Turner2015-03-051-81/+104
| | | | | | | | | | | | | | | | | | | llvm::sys::PrintBacktrace(FILE*) is supposed to print a backtrace of the current thread given the current PC. This function was unimplemented on Windows, and instead the only time we could print a backtrace was as the result of an exception through LLVMUnhandledExceptionFilter. This patch implements backtracing of self by using RtlCaptureContext to get a CONTEXT for the current thread, and moving the printing and StackWalk64 code to a common method that printing own stack trace and printing stack trace of an exception can use. Differential Revision: http://reviews.llvm.org/D8068 Reviewed by: Reid Kleckner llvm-svn: 231382
* Silence some Win64 clang-cl warnings about unused stuff due to ifdefsReid Kleckner2015-02-261-1/+2
| | | | llvm-svn: 230685
* All signal handlers are required to have C language linkage in C++. This ↵Aaron Ballman2015-01-291-1/+1
| | | | | | does not fix all signal handlers, but does fix the most recent one. llvm-svn: 227490
* [Support][Windows] Unify dialog box suppression and print stack traces on abort.Michael J. Spencer2015-01-291-20/+28
| | | | llvm-svn: 227470
OpenPOWER on IntegriCloud