Summary:
The new function sys::path::user_cache_directory tries to discover
a directory suitable for cache storage for current system user.
On Windows and Darwin it returns a path to system-specific user cache directory.
On Linux it follows XDG Base Directory Specification, what is:
- use non-empty $XDG_CACHE_HOME env var,
- use $HOME/.cache.
Reviewers: chapuni, aaron.ballman, rafael
Subscribers: rafael, aaron.ballman, llvm-commits
Differential Revision: http://reviews.llvm.org/D13801
llvm-svn: 251784
When the driver tries to locate a program by its name, e.g. a linker, it
scans the paths provided by the toolchain using the ScanDirForExecutable
function. If the lookup fails, the driver uses
llvm::sys::findProgramByName. Unlike llvm::sys::findProgramByName,
ScanDirForExecutable is not aware of file extensions. If the program has
the "exe" extension in its name, which is very common on Windows,
ScanDirForExecutable won't find it under the toolchain-provided paths.
This patch changes the Windows version of the "`can_execute`" function
called by ScanDirForExecutable to respect file extensions, similarly to
llvm::sys::findProgramByName.
Patch by Oleg Ranevskyy
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D12711
llvm-svn: 247358
If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.
Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.
llvm-svn: 243957
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
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
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
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
As noted on Errc.h:
// * std::errc is just marked with is_error_condition_enum. This means that
// common patters like AnErrorCode == errc::no_such_file_or_directory take
// 4 virtual calls instead of two comparisons.
And on some libstdc++ those virtual functions conclude that
------------------------
int main() {
std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory);
return foo == std::errc::no_such_file_or_directory;
}
-------------------------
should exit with 0.
llvm-svn: 239683
Fix two other variables that might cause the same hang fixed in r235914.
The hang is caused by constructing ManagedStatic in signalhandler. In
this case, if FileToRemove or CallBacksToRun is not contructed, it means
there is no work to do.
llvm-svn: 236741
We need to dereference the signals mutex during handler registration so that we force its construction. This is to prevent the first use being during handling an actual signal because you can't safely allocate memory in a signal handler.
llvm-svn: 235914
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
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
Older versions of the TargetConditionals header always defined TARGET_OS_IPHONE to something (0 or 1), so we need to test not only for the existence but also if it is 1.
This resolves PR22631.
llvm-svn: 229904
Should be no functional change, since most of the logic removed was
completely pointless (after some previous refactoring) and the rest
duplicated elsewhere.
Patch by Kamil Rytarowski.
llvm-svn: 228926
Use __clear_cache builtin instead of cacheflush() in
Unix Memory::InvalidateInstructionCache().
Differential Revision: http://reviews.llvm.org/D7198
llvm-svn: 227269
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
llvm-svn: 225974
In both the Unix and Windows variants, std::getenv was called and the
result passed directly to a function accepting a StringRef. This isn't
OK because it might return a null pointer and that causes the StringRef
constructor to assert (and generally produces crash-prone code if
asserts are disabled). Fix this by independently testing the result as
non-null prior to splitting things.
This in turn uncovered another bug in the Unix variant where it would
infinitely recurse if PATH="", or after this fix if PATH isn't set.
There is no need to recurse at all. Slightly re-arrange the code to make
it clear that we can just fixup the Paths argument based on the
environment if we find anything.
I don't know of a particularly useful way to test these routines in
LLVM. I'll commit a test to Clang that ensures that its driver correctly
handles various settings of PATH. However, I have no idea how to
correctly write a Windows test for the PATHEXT change. Any Windows
developers who could provide such a test, please have at. =D
Many thanks to Nick Lewycky and others for helping debug this. =/ It was
quite nasty for us to track down.
llvm-svn: 223099
Commit 220932 caused crash when building clang-tblgen on aarch64 debian target,
so it's blocking all daily tests.
The std::call_once implementation in pthread has bug for aarch64 debian.
llvm-svn: 221331
Tested this by #if 0'ing out the pthreads implementation, which
indicated that this fallback was not currently compiling successfully
and applying this patch resolves that.
Patch by Andy Chien.
llvm-svn: 220969
Summary:
This patch adds an llvm_call_once which is a wrapper around std::call_once on platforms where it is available and devoid of bugs. The patch also migrates the ManagedStatic mutex to be allocated using llvm_call_once.
These changes are philosophically equivalent to the changes added in r219638, which were reverted due to a hang on Win32 which was the result of a bug in the Windows implementation of std::call_once.
Reviewers: aaron.ballman, chapuni, chandlerc, rnk
Reviewed By: rnk
Subscribers: majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D5922
llvm-svn: 220932
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
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
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
We won't link in pthreads if we weren't built with LLVM_ENABLE_THREADS
which means we won't get access to pthread_sigmask. Use sigprocmask
instead.
llvm-svn: 219288
Most Unix-like operating systems guarantee that the file descriptor is
closed after a call to close(2), even if close comes back with EINTR.
For these systems, calling close _again_ will either do nothing or close
some other file descriptor open(2)'d by another thread. (Linux)
However, some operating systems do not have this behavior. They require
at least another call to close(2) before guaranteeing that the
descriptor is closed. (HP-UX)
And some operating systems have an unpredictable blend of the two
behaviors! (xnu)
Avoid this disaster by blocking all signals before we call close(2).
This ensures that a signal will not be delivered to the thread and
close(2) will not give us back EINTR. We restore the signal mask once
the operation is done.
N.B. This isn't a problem on Windows, it doesn't have a notion of EINTR
because signals always get delivered to dedicated signal handling
threads.
llvm-svn: 219189
It's possible to start a program with one (or all) of the standard file
descriptors closed. Subsequent open system calls will give the program
a low-numbered file descriptor.
This is problematic because we may believe we are writing to standard
out instead of a file.
Introduce Process::FixupStandardFileDescriptors, a helper function to
remap standard file descriptors to /dev/null if they were closed before
the program started.
llvm-svn: 219170
The main difference is the removal of
std::error_code exists(const Twine &path, bool &result);
It was an horribly redundant interface since a file not existing is also a valid
error_code. Now we have an access function that returns just an error_code. This
is the only function that has to be implemented for Unix and Windows. The
functions can_write, exists and can_execute an now just wrappers.
One still has to be very careful using these function to avoid introducing
race conditions (Time of check to time of use).
llvm-svn: 217625
This patch adds to LLVMSupport the capability of writing files with
international characters encoded in the current system encoding. This
is relevant for Windows, where we can either use UTF16 or the current
code page (the legacy Windows international characters). On UNIX, the
file is always saved in UTF8.
This will be used in a patch for clang to thoroughly support response
files creation when calling other tools, addressing PR15171. On
Windows, to correctly support internationalization, we need the
ability to write response files both in UTF16 or the current code
page, depending on the tool we will call. GCC for mingw, for instance,
requires files to be encoded in the current code page. MSVC tools
requires files to be encoded in UTF16.
Patch by Rafael Auler!
llvm-svn: 217068
We had two functions for finding the temp or cache directory. Each had a
different set of smarts about OS specific APIs.
With this patch system_temp_directory becomes the only way to do it.
llvm-svn: 216460
This patch fixes a subtle bug in the UNIX implementation of
llvm::sys::argumentsFitWithinSystemLimits() regarding the misuse of a static
variable. This bug causes our cached number that stores the system command line
maximum length to be halved after each call to the function. With a sufficient
number of calls to this function, it will eventually report any given command
line string to be over system limits.
Patch by Rafael Auler.
llvm-svn: 216415
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
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)
Changes made by clang-tidy with minor tweaks.
llvm-svn: 215558
Some versions of Android don't have futimes/futimens and this code wasn't
updated during the recent errc refactoring.
Patch by Luqman Aden!
llvm-svn: 212055
where there is no timeout. In the case where there is a timeout though, the
code is still wrong since it doesn't check that the alarm really went off.
Without this patch, I cannot debug a program that forks itself using
sys::ExecuteAndWait with lldb.
llvm-svn: 211918
Buildbot reports a test failure on the llvm-mips-linux builder and blames r211588.
Although it doesn't appear in the blamelist, it seems it could also be r211587
(because it's committed to compiler-rt?) since they were tested together.
Reverting the most likely suspect (r211588) to confirm one way or the other.
llvm-svn: 211594
MIPS64 Android bionic has removed cacheflush(). Use __clear_cache() instead for 32-bit and 64-bit MIPS
Patch by Duane Sand <Duane.Sand@imgtec.com>
llvm-svn: 211588
While std::error_code itself seems to work OK in all platforms, there
are few annoying differences with regards to the std::errc enumeration.
This patch adds a simple llvm enumeration, which will hopefully avoid build
breakages in other platforms and surprises as we get more uses of
std::error_code.
llvm-svn: 210920
The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace. I will remove it shortly afterwards.
The cases where the general idea needed some tweaking:
* std::errc is a namespace in msvc, so we cannot use "using std::errc". I could
add an #ifdef, but there were not that many uses, so I just added std:: to
them in this patch.
* Template specialization had to be moved to the std namespace in this
patch set already.
* The msvc implementation of default_error_condition doesn't seem to
provide the same transformations as we need. Not too surprising since
the standard doesn't actually say what "equivalent" means. I fixed the
problem by keeping our old mapping and using it at error_code
construction time.
Despite these shortcomings I think this is still a good thing. Some reasons:
* The different implementations of system_error might improve over time.
* It removes 925 lines of code from llvm already.
* It removes 6313 bytes from the text segment of the clang binary when
it is built with gcc and 2816 bytes when building with clang and
libstdc++.
llvm-svn: 210687
Some c++ libraries (libstdc++ at least) don't seem to map to the generic
category in in the system_category's default_error_condition.
llvm-svn: 210635
each line. This is particularly nice for tracking which run of
a particular pass over a particular function was slow.
This also required making the TimeValue string much more useful. First,
there is a standard format for writing out a date and time. Let's use
that rather than strings that would have to be parsed. Second, actually
output the nanosecond resolution that timevalue claims to have.
This is proving useful working on PR19499, so I figured it would be
generally useful to commit.
llvm-svn: 207385
This will fix cross-compiling buildbots (e.g. cygwin). This is in the same vein
as SVN r205070. Apply this to fix the cross-compiling scenario, even though the
preferred solution is to update the build system to normalize the embedded
triple rather than perform this at runtime every time. This is meant to tide us
over until that approach is fleshed out and applied.
llvm-svn: 205120
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
Add a utility function to convert the Windows path separator to Unix style path
separators. This is used by a subsequent change in clang to enable the use of
Windows SDK headers on Linux.
llvm-svn: 203611
Before this patch the unix code for creating hardlinks was unused. The code
for creating symbolic links was implemented in lib/Support/LockFileManager.cpp
and the code for creating hard links in lib/Support/*/Path.inc.
The only use we have for these is in LockFileManager.cpp and it can use both
soft and hard links. Just have a create_link function that creates one or the
other depending on the platform.
llvm-svn: 203596
Pawel Bylica