summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix/Signals.inc
Commit message (Collapse)AuthorAgeFilesLines
* [Support][Windows] Unify dialog box suppression and print stack traces on abort.Michael J. Spencer2015-01-291-0/+2
| | | | llvm-svn: 227470
* Remove FindProgramByName. NFC.Rafael Espindola2014-11-041-2/+4
| | | | llvm-svn: 221258
* Strength reduce constant-sized vectors into arrays. No functionality change.Benjamin Kramer2014-10-221-8/+6
| | | | llvm-svn: 220412
* Unix/Signals.inc: Let findModulesAndOffsets() built conditionally regarding ↵NAKAMURA Takumi2014-10-131-2/+3
| | | | | | to (defined(HAVE_BACKTRACE) && defined(ENABLE_BACKTRACES)). [-Wunused-function] llvm-svn: 219596
* Guard the definition of the stack tracing function with the same macrosChandler Carruth2014-10-111-0/+2
| | | | | | | that guard its usage. Without this, we can get unused function warnings when backtraces are disabled. llvm-svn: 219558
* Follow-up to r219534 to make symbolization more robust.Alexey Samsonov2014-10-101-2/+7
| | | | | | | | | | 1) Explicitly provide important arguments to llvm-symbolizer, not relying on defaults. 2) Be more defensive about symbolizer output. This might fix weird failures on ninja-x64-msvc-RA-centos6 buildbot. llvm-svn: 219541
* Re-land r219354: Use llvm-symbolizer to symbolize LLVM/Clang crash dumps.Alexey Samsonov2014-10-101-1/+140
| | | | | | | | | | | | In fact, symbolization is now expected to work only on Linux and FreeBSD/NetBSD, where we have dl_iterate_phdr and can learn the main executable name without argv0 (it will be possible on BSD systems after http://reviews.llvm.org/D5693 lands). #ifdef-out the code for all the rest Unix systems. Reviewed in http://reviews.llvm.org/D5610 llvm-svn: 219534
* Revert r219354. It seems to break some buildbots.Alexey Samsonov2014-10-081-139/+1
| | | | llvm-svn: 219355
* Use llvm-symbolizer to symbolize LLVM/Clang crash dumps.Alexey Samsonov2014-10-081-1/+139
| | | | | | | | | | | | | | | | This change modifies fatal signal handler used in LLVM tools. Now it attempts to find llvm-symbolizer binary and communicates with it in order to turn instruction addresses into function/file/line info entries. This should significantly improve stack traces readability in Debug builds. This feature only works on selected platforms (including Darwin and Linux). If the symbolization fails for some reason, signal handler will fallback to the original behavior. Reviewed in http://reviews.llvm.org/D5610 llvm-svn: 219354
* Cleaning up remaining static initializers in Signals.incChris Bieneman2014-09-021-24/+31
| | | | llvm-svn: 216996
* Cleaning up static initializers in Signals.incChris Bieneman2014-08-291-5/+4
| | | | | | Reviewed by: Chandlerc llvm-svn: 216704
* Support: add llvm::unique_lockDylan Noblesmith2014-08-231-16/+17
| | | | | | | | | | | | | | | Based on the STL class of the same name, it guards a mutex while also allowing it to be unlocked conditionally before destruction. This eliminates the last naked usages of mutexes in LLVM and clang. It also uncovered and fixed a bug in callExternalFunction() when compiled without USE_LIBFFI, where the mutex would never be unlocked if the end of the function was reached. llvm-svn: 216338
* Support: make LLVM Mutexes STL-compatibleDylan Noblesmith2014-08-231-4/+4
| | | | | | Use lock/unlock() convention instead of acquire/release(). llvm-svn: 216336
* Support/Unix: use ScopedLock wherever possibleDylan Noblesmith2014-08-231-24/+22
| | | | | | | Only one function remains a bit too complicated for a simple mutex guard. No functionality change. llvm-svn: 216335
* [C++] Use 'nullptr'.Craig Topper2014-04-281-14/+14
| | | | llvm-svn: 207394
* Retire llvm::array_endof in favor of non-member std::end.Benjamin Kramer2014-04-121-2/+2
| | | | | | While there make array_lengthof constexpr if we have support for it. llvm-svn: 206112
* [conf] Add config variable to disable crash related overrides.Daniel Dunbar2013-08-301-2/+2
| | | | | | | | | | | | | | | | | | | | | - We do some nasty things w.r.t. installing or overriding signal handlers in order to improve our crash recovery support or interaction with crash reporting software, and those things are not necessarily appropriate when LLVM is being linked into a client application that has its own ideas about how to do things. This gives those clients a way to disable that handling at build time. - Currently, the code this guards is all Apple specific, but other platforms might have the same concerns so I went for a more generic configure name. Someone who is more familiar with library embedding on Windows can handle choosing which of the Windows/Signals.inc behaviors might make sense to go under this flag. - This also fixes the proper autoconf'ing of ENABLE_BACKTRACES. The code expects it to be undefined when disabled, but the autoconf check was just defining it to 0. llvm-svn: 189694
* Revert part of 186302 to fix buildbots.Craig Topper2013-07-151-1/+2
| | | | llvm-svn: 186303
* Use llvm::array_lengthof to replace sizeof(array)/sizeof(array[0]).Craig Topper2013-07-151-6/+3
| | | | llvm-svn: 186301
* Don't use PathV1.h in Signals.h.Rafael Espindola2013-06-131-4/+4
| | | | llvm-svn: 183947
* [SystemZ] Support System Z as host architectureUlrich Weigand2013-05-031-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The llvm::sys::AddSignalHandler function (as well as related routines) in lib/Support/Unix/Signals.inc currently registers a signal handler routine via "sigaction". When this handler is called due to a SIGSEGV, SIGILL or similar signal, it will show a stack backtrace, deactivate the handler, and then simply return to the operating system. The intent is that the OS will now retry execution at the same location as before, which ought to again trigger the same error condition and cause the same signal to be delivered again. Since the hander is now deactivated, the OS will take its default action (usually, terminate the program and possibly create a core dump). However, this method doesn't work reliably on System Z: With certain signals (namely SIGILL, SIGFPE, and SIGTRAP), the program counter stored by the kernel on the signal stack frame (which is the location where execution will resume) is not the instruction that triggered the fault, but then instruction *after it*. When the LLVM signal handler simply returns to the kernel, execution will then resume at *that* address, which will not trigger the problem again, but simply go on and execute potentially unrelated code leading to random errors afterwards. To fix this, the patch simply goes and re-raises the signal in question directly from the handler instead of returning from it. This is done only on System Z and only for those signals that have this particular problem. llvm-svn: 181010
* Inline variable into the #ifdef block where it's used.Benjamin Kramer2013-04-281-1/+1
| | | | llvm-svn: 180688
* Fix typo. Stupid me.Joerg Sonnenberger2013-04-271-1/+1
| | | | llvm-svn: 180686
* Only use cxxabi.h's demangler, if it is actually available.Joerg Sonnenberger2013-04-271-2/+8
| | | | llvm-svn: 180684
* Rewrite comments.Dan Gohman2013-02-201-3/+5
| | | | llvm-svn: 175651
* SIGQUIT is a "kill" signal, rather than an "int" signal, in this context.Dan Gohman2013-02-201-2/+2
| | | | llvm-svn: 175648
* Fix gcc/printf/ISO C++ warningEdwin Vane2013-01-281-1/+5
| | | | | | | | | | | | Remove the use of the 't' length modifier to avoid a gcc warning. Based on usage, 32 bits of precision is good enough for printing a stack offset for a stack trace. 't' length modifier isn't in C++03 but it *is* in C++11. Added a FIXME to reintroduce once LLVM makes the switch to C++11. Reviewer: gribozavr llvm-svn: 173711
* Move the internal PrintStackTrace function that is used for ↵Argyrios Kyrtzidis2013-01-091-11/+15
| | | | | | | | llvm::sys::PrintStackTraceOnErrorSignal(), into a new function llvm::sys::PrintStackTrace, so that it's available to clients for logging purposes. llvm-svn: 171989
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Support: Don't remove special files on signals.Daniel Dunbar2012-10-171-9/+21
| | | | | | | - Similar to Path::eraseFromDisk(), we don't want LLVM to remove things like /dev/null, even if it has the permission. llvm-svn: 166105
* Make backtraces work again with both the configure and cmake build.Benjamin Kramer2012-09-281-1/+1
| | | | llvm-svn: 164817
* Add an --enable-backtraces option to configure to determineEric Christopher2012-09-211-1/+1
| | | | | | | | | whether or not we want to print out backtrace information. Useful for libraries that don't need backtrace information on a crash. rdar://11844710 llvm-svn: 164426
* Whitespace.NAKAMURA Takumi2012-09-061-2/+2
| | | | llvm-svn: 163289
* Unix/Signals.inc: Fix a typo. Thanks to Dani Berg!NAKAMURA Takumi2012-09-061-1/+1
| | | | llvm-svn: 163288
* Don't call 'FilesToRemove[0]' when the vector is empty, even to computeChandler Carruth2012-06-161-1/+1
| | | | | | | the address of it. Found by a checking STL implementation used on a dragonegg builder. Sorry about this one. =/ llvm-svn: 158582
* Harden the Unix signals code to be more async signal safe.Chandler Carruth2012-06-161-9/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is likely only the tip of the ice berg, but this particular bug caused any double-free on a glibc system to turn into a deadlock! It is not generally safe to either allocate or release heap memory from within the signal handler. The 'pop_back()' in RemoveFilesToRemove was deleting memory and causing the deadlock. What's worse, eraseFromDisk in PathV1 has lots of allocation and deallocation paths. We even passed 'true' in a place that would have caused the *signal handler* to try to run the 'system' system call and shell out to 'rm -rf'. That was never going to work... This patch switches the file removal to use a vector of strings so that the exact text needed for the 'unlink' system call can be stored there. It switches the loop to be a boring indexed loop, and directly calls unlink without looking at the error. It also works quite hard to ensure that calling 'c_str()' is safe, by ensuring that the non-signal-handling code path that manipulates the vector always leaves it in a state where every element has already had 'c_str()' called at least once. I dunno exactly how overkill this is, but it fixes the deadlock-on-double free issue, and seems likely to prevent any other issues from sneaking up. Sorry for not having a test case, but I *really* don't know how to test signal handling code easily.... llvm-svn: 158580
* Fix null to integer conversion warnings.Jean-Daniel Dupas2012-03-241-2/+2
| | | | llvm-svn: 153395
* Disable the crash reporter when running lit tests.Argyrios Kyrtzidis2012-01-111-0/+20
| | | | llvm-svn: 147965
* Include <pthread.h> before we use pthread_self/pthread_killDouglas Gregor2011-04-291-3/+3
| | | | llvm-svn: 130510
* Fix a ton of comment typos found by codespell. Patch byChris Lattner2011-04-151-1/+1
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129558
* Merge System into Support.Michael J. Spencer2010-11-291-0/+303
llvm-svn: 120298
OpenPOWER on IntegriCloud