summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix
Commit message (Collapse)AuthorAgeFilesLines
* Don't use PathV1.h in Signals.h.Rafael Espindola2013-06-131-4/+4
| | | | llvm-svn: 183947
* Have sys::FindProgramByName return a std::string.Rafael Espindola2013-06-131-7/+7
| | | | llvm-svn: 183928
* [Support] Fix handle and memory leak for processes that are not waited forReid Kleckner2013-06-131-8/+6
| | | | | | | | | | | | Execute's Data parameter is now optional, so we won't allocate memory for it on Windows and we'll close the process handle. The Unix code should probably do something similar to avoid accumulation of zombie children that haven't been waited on. Tested on Linux and Windows. llvm-svn: 183906
* Remove the program class.Rafael Espindola2013-06-121-21/+17
| | | | | | | It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just those two functions and make Execute and Wait implementations details. llvm-svn: 183864
* Remove Path::getMagicNumber.Rafael Espindola2013-06-121-14/+0
| | | | llvm-svn: 183839
* Remove Path::isAbsolute.Rafael Espindola2013-06-121-8/+0
| | | | llvm-svn: 183836
* Remove Path::isAbsolute().Rafael Espindola2013-06-121-7/+0
| | | | llvm-svn: 183835
* Remove Path::getSuffix.Rafael Espindola2013-06-121-17/+0
| | | | llvm-svn: 183833
* Remove sys::CopyFile.Rafael Espindola2013-06-121-47/+0
| | | | llvm-svn: 183831
* Remove the old file memory mapping functions.Rafael Espindola2013-06-121-17/+0
| | | | llvm-svn: 183828
* Remove Path::createFileOnDisk.Rafael Espindola2013-06-121-10/+0
| | | | llvm-svn: 183827
* Remove Path::makeExecutableOnDisk.Rafael Espindola2013-06-121-6/+0
| | | | llvm-svn: 183826
* Remove Path::getDirname.Rafael Espindola2013-06-111-4/+0
| | | | llvm-svn: 183780
* Remove Path::getBasename.Rafael Espindola2013-06-111-16/+0
| | | | llvm-svn: 183779
* Remove Path::getLast.Rafael Espindola2013-06-111-22/+0
| | | | llvm-svn: 183778
* Remove GetRootDirectory.Rafael Espindola2013-06-111-7/+0
| | | | llvm-svn: 183775
* Remove GetUserHomeDirectory.Rafael Espindola2013-06-111-10/+0
| | | | llvm-svn: 183773
* Remove GetSystemLibraryPaths.Rafael Espindola2013-06-111-15/+0
| | | | llvm-svn: 183770
* Remove Path::GetBitcodeLibraryPaths.Rafael Espindola2013-06-111-17/+0
| | | | llvm-svn: 183765
* Remove declaration of __clear_cache for __APPLE__. <rdar://problem/13924072>Bob Wilson2013-05-191-0/+3
| | | | | | | | | | | | | | | This fixes a bootstrapping problem with builds for Apple ARM targets. Clang had the wrong prototype for __clear_cache with ARM targets. Rafael fixed that in clang svn r181784 and r181810, but without those changes, we can't build this code for ARM because clang reports an error about the declaration in Memory.inc not matching the builtin declaration. Some of our buildbots need to use an older compiler that doesn't have the clang fix. Since __clear_cache is never used here when __APPLE__ is defined, I'm just conditionalizing the declaration to match that. I also moved the declaration of sys_icache_invalidate inside the conditional for __APPLE__ while I was at it. llvm-svn: 182223
* Invalidate instruction cache when setting memory to be executable.Tim Northover2013-05-191-0/+3
| | | | | | | | | lli's remote MCJIT code calls setExecutable just prior to running code. In line with Darwin behaviour this seems to be the place to invalidate any caches needed so that relocations can take effect properly. llvm-svn: 182213
* Fix __clear_cache declaration.Rafael Espindola2013-05-141-1/+1
| | | | | | This fixes the build with gcc in gnu++98 and gnu++11 mode. llvm-svn: 181811
* Declare __clear_cache.Rafael Espindola2013-05-141-0/+1
| | | | | | | | GCC declares __clear_cache in the gnu modes (-std=gnu++98, -std=gnu++11), but not in the strict modes (-std=c++98, -std=c++11). This patch declares it and therefore fixes the build when using one of the strict modes. llvm-svn: 181785
* AArch64: use __clear_cache under GCCish environmentsTim Northover2013-05-041-1/+1
| | | | | | | | | AArch64 is going to need some kind of cache-invalidation in order to successfully JIT since it has a weak memory-model. This is provided by a __clear_cache builtin in libgcc, which acts very much like the 32-bit ARM equivalent (on platforms where it exists). llvm-svn: 181129
* [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
* Add a function to check if an argument list is too long.Rafael Espindola2013-04-111-0/+24
| | | | | | | | | This will be used in clang to decide if it should create an @file or not. It will be tested on the clang side. Patch by Nathan Froyd. llvm-svn: 179285
* <rdar://problem/13551789> Fix yet another race in unique_file.Douglas Gregor2013-04-051-3/+1
| | | | | | | | | If the directory that will contain the unique file doesn't exist when we tried to create the file, but another process creates it before we get a chance to try creating it, we would bail out rather than try to create the unique file. llvm-svn: 178908
* Add a new watchdog timer interface. The interface does not permit handling ↵Nick Lewycky2013-03-261-0/+32
| | | | | | | | | timeouts, so it's only really useful if you're going to crash anyways. Use it in the pretty stack trace printer to kill the compiler if we hang while printing the stack trace. llvm-svn: 177962
* Android uses cacheflush(long start, long end, long flags) for MIPS.Akira Hatanaka2013-03-141-0/+9
| | | | | | Patch by Stephen Hines. llvm-svn: 177101
* [Support] Fix lifetime of file descriptors when using MemoryBuffer.Michael J. Spencer2013-03-141-7/+10
| | | | | | | Clients of MemoryBuffer::getOpenFile expect it not to take ownership of the file descriptor passed in. So don't. llvm-svn: 176995
* [PathV2] In llvm::sys::fs::unique_file, make sure it doesn't fall into an ↵Argyrios Kyrtzidis2013-02-281-1/+7
| | | | | | | | | | | infinite loop by constantly trying to create the parent path. This can happen if the path is a relative filename and the current directory was removed. Thanks to Daniel D. for the hint in fixing it. llvm-svn: 176226
* Rewrite comments.Dan Gohman2013-02-201-3/+5
| | | | llvm-svn: 175651
* Add comment in Memory.inc explaining r175646.Krzysztof Parzyszek2013-02-201-0/+7
| | | | llvm-svn: 175650
* SIGQUIT is a "kill" signal, rather than an "int" signal, in this context.Dan Gohman2013-02-201-2/+2
| | | | llvm-svn: 175648
* On PowerPC, the cache-flush instructions dcbf and icbi are treated asKrzysztof Parzyszek2013-02-201-0/+4
| | | | | | | loads. On FreeBSD, add PROT_READ page protection flag before flushing cache. llvm-svn: 175646
* Fix initialization-order bug in llvm::Support::TimeValue. TimeValue::now() ↵Alexey Samsonov2013-02-191-1/+2
| | | | | | is explicitly called during module initialization of lib/Support/Process.cpp. It reads the field of global object PosixZeroTime, which is not guaranteed to be initialized at this point. Found by AddressSanitizer with -fsanitize=init-order option. llvm-svn: 175509
* Workaround an MSan false positive.Evgeniy Stepanov2013-02-141-0/+2
| | | | llvm-svn: 175156
* More MSan/ASan annotations.Evgeniy Stepanov2013-02-041-0/+5
| | | | | | | | | | | | | | This change lets us bootstrap LLVM/Clang under ASan and MSan. It contains fixes for 2 issues: - X86JIT reads return address from stack, which MSan does not know is initialized. - bugpoint tests run binaries with RLIMIT_AS. This does not work with certain Sanitizers. We are no longer including config.h in Compiler.h with this change. llvm-svn: 174306
* 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
* Fix a race condition in llvm::sys::path::unique_file: when we end upDouglas Gregor2013-01-101-4/+7
| | | | | | | failing to create the unique file because the path doesn't exist, don't fail if someone else manages to create the path before we do. llvm-svn: 172032
* 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
* Eric thought that Darwin was right to use -1 consistently rather thanChandler Carruth2013-01-051-1/+1
| | | | | | | | | | | leaving this undefined, and despite the sentence in the standard that seems to require it, I'll cede the point and assume its a bug in the wording. Other parts of POSIX regularly allow for things to be -1 instead of undefined, this should too. Makes things more consistent too. This should have to real impact for folks though. llvm-svn: 171574
* Try to suppress the use of clock_gettime on Darwin which apparantlyChandler Carruth2013-01-051-1/+1
| | | | | | | | | | | | | | | | | defines _POSIX_CPUTIME but doesn't support the clock_* functions. I don't test the value of _POSIX_CPUTIME because the spec merely says that if it is defined, the CPU-specific timers are available, whereas it says that _POSIX_TIMERS must be defined and defined to a value greater than zero. However, this may not work, as the POSIX spec clearly states: "If the symbolic constant _POSIX_CPUTIME is defined, then the symbolic constant _POSIX_TIMERS shall also be defined by the implementation to have the value 200112L." If this doesn't work, I'll add more hacks for Darwin. llvm-svn: 171565
* Add time getters to the process interface for requesting the elapsedChandler Carruth2013-01-041-22/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wall time, user time, and system time since a process started. For walltime, we currently use TimeValue's interface and a global initializer to compute a close approximation of total process runtime. For user time, this adds support for an somewhat more precise timing mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock selected. For system time, we have to do a full getrusage call to extract the system time from the OS. This is expensive but unavoidable. In passing, clean up the implementation of the old APIs and fix some latent bugs in the Windows code. This might have manifested on Windows ARM systems or other systems with strange 64-bit integer behavior. The old API for this both user time and system time simultaneously from a single getrusage call. While this results in fewer system calls, it also results in a lower precision user time and if only user time is desired, it introduces a higher overhead. It may be worthwhile to switch some of the pass timers to not track system time and directly track user and wall time. The old API also tracked walltime in a confusing way -- it just set it to the current walltime rather than providing any measure of wall time since the process started the way buth user and system time are tracked. The new API is more consistent here. The plan is to eventually implement these methods for a *child* process by using the wait3(2) system call to populate an rusage struct representing the whole subprocess execution. That way, after waiting on a child process its stats will become accurate and cheap to query. llvm-svn: 171551
* Remove an unused method on Program.Chandler Carruth2012-12-311-18/+0
| | | | | | | I'm simplifying this interface as much as I can before merging it with the new process interface. llvm-svn: 171334
* Remove an unused method on the Program class.Chandler Carruth2012-12-311-5/+0
| | | | llvm-svn: 171332
* Go ahead and get rid of the old page size interface and convert all theChandler Carruth2012-12-312-9/+9
| | | | | | | users over to the new one. No sense maintaining this "compatibility" layer it seems. llvm-svn: 171331
OpenPOWER on IntegriCloud