summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix/Signals.inc
Commit message (Collapse)AuthorAgeFilesLines
* Fix namespaces. No functionality change.Benjamin Kramer2018-06-161-0/+2
| | | | llvm-svn: 334890
* Signal handling should be signal-safeJF Bastien2018-05-161-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-161/+73
| | | | | | 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-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] pull a function into its own lambdaJF Bastien2018-05-151-19/+21
| | | | | | | | | As requested in D46858, pulling this function into its own lambda makes it easier to read that part of the code and reason as to what's going on because the scope it can be called from is extremely limited. We want to keep it as a function because it's called from the two subsequent lines. llvm-svn: 332325
* [NFC] Update commentsJF Bastien2018-05-151-20/+19
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+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
* Report fatal error in the case of out of memorySerge Pavlov2018-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-151-1/+1
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Report fatal error in the case of out of memorySerge Pavlov2018-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Fix detection of backtrace() availability on FreeBSDEd Maste2017-04-121-2/+2
| | | | | | | | | | | | On FreeBSD backtrace is not part of libc and depends on libexecinfo being available. Instead of using manual checks we can use the builtin CMake module FindBacktrace.cmake to detect availability of backtrace() in a portable way. Patch By: Alex Richardson Differential Revision: https://reviews.llvm.org/D27143 llvm-svn: 300062
* Remove name space pollution from Signals.cppKristof Beyls2017-03-311-3/+3
| | | | llvm-svn: 299224
* [Support] Avoid concurrency hazard in signal handler registrationBruno Cardoso Lopes2017-03-271-5/+1
| | | | | | | | | | | | | | | | | | Several static functions from the signal API can be invoked simultaneously; RemoveFileOnSignal for instance can be called indirectly by multiple parallel loadModule() invocations, which might lead to the assertion: Assertion failed: (NumRegisteredSignals < array_lengthof(RegisteredSignalInfo) && "Out of space for signal handlers!"), function RegisterHandler, file /llvm/lib/Support/Unix/Signals.inc, line 105. RemoveFileOnSignal calls RegisterHandlers(), which isn't currently mutex protected, leading to the behavior above. This potentially affect a few other users of RegisterHandlers() too. rdar://problem/30381224 llvm-svn: 298871
* Fix LLDB Android AArch64 GCC debug info buildOmair Javaid2017-02-021-1/+1
| | | | | | | | | Committing after fixing suggested changes and tested release/debug builds on x86_64-linux and arm/aarch64 builds. Differential revision: https://reviews.llvm.org/D29042 llvm-svn: 293850
* Revert "Use _Unwind_Backtrace on Apple platforms."Bob Wilson2017-01-061-1/+1
| | | | | | | | | | | This reverts commit 63165f6ae3bac1623be36d4b3ce63afa1d51a30a. After making this change, I discovered that _Unwind_Backtrace is unable to unwind past a signal handler after an assertion failure. I filed a bug report about that issue in rdar://29866587 but even if we get a fix soon, it will be awhile before it get released. llvm-svn: 291207
* Use _Unwind_Backtrace on Apple platforms.Bob Wilson2016-11-141-1/+1
| | | | | | | | | | | | | Darwin's backtrace() function does not work with sigaltstack (which was enabled when available with r270395) — it does a sanity check to make sure that the current frame pointer is within the expected stack area (which it is not when using an alternate stack) and gives up otherwise. The alternative of _Unwind_Backtrace seems to work fine on macOS, so use that when backtrace() fails. Note that we then use backtrace_symbols_fd() with the addresses from _Unwind_Backtrace, but I’ve tested that and it also seems to work fine. rdar://problem/28646552 llvm-svn: 286851
* fix build on cygwinNuno Lopes2016-10-061-1/+1
| | | | | | Cygwin has dlfcn.h, but no Dl_info llvm-svn: 283427
* Turn ENABLE_CRASH_OVERRIDES into a 0/1 definition.Joerg Sonnenberger2016-09-301-1/+1
| | | | llvm-svn: 282919
* Convert ENABLE_BACKTRACES into a 0/1 definition.Joerg Sonnenberger2016-09-301-4/+4
| | | | llvm-svn: 282918
* HAVE_UNWIND_BACKTRACE -> HAVE__UNWIND_BACKTRACEJoerg Sonnenberger2016-09-291-4/+4
| | | | | | Check for existance and not truth value. llvm-svn: 282767
* Add an c++ itanium demangler to llvm.Rafael Espindola2016-09-061-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a copy of the demangler in libcxxabi. The code also has no dependencies on anything else in LLVM. To enforce that I added it as another library. That way a BUILD_SHARED_LIBS will fail if anyone adds an use of StringRef for example. The no llvm dependency combined with the fact that this has to build on linux, OS X and Windows required a few changes to the code. In particular: No constexpr. No alignas On OS X at least this library has only one global symbol: __ZN4llvm16itanium_demangleEPKcPcPmPi My current plan is: Commit something like this Change lld to use it Change lldb to use it as the fallback Add a few #ifdefs so that exactly the same file can be used in libcxxabi to export abi::__cxa_demangle. Once the fast demangler in lldb can handle any names this implementation can be replaced with it and we will have the one true demangler. llvm-svn: 280732
* Preserve a pointer to the newly allocated signal stack as well. That tooChandler Carruth2016-08-241-4/+6
| | | | | | is flagged by LSan at least among leak detectors. llvm-svn: 279605
* Increase the size of the sigaltstack used by LLVM signal handlers. 8KB is notRichard Smith2016-08-241-1/+1
| | | | | | | | sufficient in some cases; increase to 64KB, which should be enough for anyone :) Patch by github.com/bryant! llvm-svn: 279599
* 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
* 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] Reapply cleanup r270643Gerolf Hoflehner2016-05-251-39/+0
| | | | llvm-svn: 270674
* [Support] revert previous commit r270643Gerolf Hoflehner2016-05-251-0/+39
| | | | llvm-svn: 270670
* [Support] Cleanup of an ancient Darwin work-around in Signals.inc (PR26174)Gerolf Hoflehner2016-05-251-39/+0
| | | | | | Patch by Jeremy Huddleston Sequoia llvm-svn: 270643
* Enable use of sigaltstack for signal handlers when available. With this,Richard Smith2016-05-231-1/+1
| | | | | | | backtraces from the signal handler on stack overflow now work reliably (on my system at least...). llvm-svn: 270395
* Fix implicit type conversion. NFC.Chris Bieneman2016-05-211-1/+1
| | | | llvm-svn: 270299
* Switch from the linux-specific 'struct sigaltstack' to POSIX's 'stack_t'. ThisRichard Smith2016-05-201-2/+2
| | | | | | is what I get for trusting my system's man pages I suppose. llvm-svn: 270280
* Add a configure-time check for the existence of sigaltstack. It seems that someRichard Smith2016-05-201-2/+4
| | | | | | systems provide a <signal.h> that doesn't declare it. llvm-svn: 270278
* Reinstate r269992 (reverting r270267), but restricted to cases where glibc isRichard Smith2016-05-201-4/+59
| | | | | | | | | the C standard library implementation in use. This works around a glibc bug in the backtrace() function where it fails to produce a backtrace on x86_64 if libgcc / libunwind is statically linked. llvm-svn: 270276
* Create a sigaltstack when we register our signal handlers. Otherwise we'd veryRichard Smith2016-05-201-0/+31
| | | | | | likely fail to produce a backtrace if we crash due to stack overflow. llvm-svn: 270273
* Revert "Work around a glibc bug: backtrace() spuriously fails if..."Chris Bieneman2016-05-201-51/+4
| | | | | | | | | This commit has been breaking the FreeBSD bots: http://lab.llvm.org:8011/builders/lld-x86_64-freebsd This reverts commit r269992. llvm-svn: 270267
* Work around a glibc bug: backtrace() spuriously fails ifRichard Smith2016-05-181-4/+51
| | | | | | | | | | | | - glibc is dynamically linked, and - libgcc_s is unavailable (for instance, another library is being used to provide the compiler runtime or libgcc is statically linked), and - the target is x86_64. If we run backtrace() and it fails to find any stack frames, try using _Unwind_Backtrace instead if available. llvm-svn: 269992
* Revert "Fix Clang-tidy modernize-deprecated-headers warnings in remaining ↵Duncan P. N. Exon Smith2016-04-051-29/+24
| | | | | | | | | | files; other minor fixes." This reverts commit r265454 since it broke the build. E.g.: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/22413/ llvm-svn: 265459
* Fix Clang-tidy modernize-deprecated-headers warnings in remaining files; ↵Eugene Zelenko2016-04-051-24/+29
| | | | | | | | | | | | other minor fixes. Some Include What You Use suggestions were used too. Use anonymous namespaces in source files. Differential revision: http://reviews.llvm.org/D18778 llvm-svn: 265454
* Use array_lengthof instead of manually calculating it. NFCCraig Topper2015-12-011-3/+2
| | | | llvm-svn: 254380
* Combine ifdefs around dl_iterate_phdr in Unix/Signals.incReid Kleckner2015-11-091-13/+8
| | | | | | | This avoids the need to have two dummy implementations of findModulesAndOffsets. llvm-svn: 252531
* Appease hosts without HAVE_BACKTRACE nor ENABLE_BACKTRACES.NAKAMURA Takumi2015-11-081-0/+7
| | | | | | | llvm/lib/Support/Signals.cpp:66:13: warning: unused function 'printSymbolizedStackTrace' [-Wunused-function] llvm/lib/Support/Signals.cpp:52:13: warning: function 'findModulesAndOffsets' has internal linkage but is not defined [-Wundefined-internal] llvm-svn: 252418
* Fix OSX build after r252118 (missing parameter for findModulesAndOffsets())Mehdi Amini2015-11-051-1/+2
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252137
* Remove empty linesMehdi Amini2015-11-051-2/+2
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252136
* [Windows] Symbolize with llvm-symbolizer instead of dbghelp in a self-hostReid Kleckner2015-11-051-87/+2
| | | | | | | | | | | | | | | | 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
* Remove unnecessary in C++11 c_str() callsYaron Keren2015-07-231-18/+1
| | | | | | | | While theoratically required in pre-C++11 to avoid re-allocation upon call, C++11 guarantees that c_str() returns a pointer to the internal array so pre-calling c_str() is no longer required. llvm-svn: 242983
* 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-9/+1
| | | | | | | | | 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
* Remove C++98 workaround in llvm::sys::DontRemoveFileOnSignal()Yaron Keren2015-07-221-7/+0
| | | | llvm-svn: 242920
* Use auto instead of the long type name. NFC.Steven Wu2015-05-071-2/+1
| | | | llvm-svn: 236768
OpenPOWER on IntegriCloud