summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows
Commit message (Collapse)AuthorAgeFilesLines
* Improve long path name support on Windows.Paul Robinson2014-11-131-38/+66
| | | | | | | | | | Windows normally limits the length of an absolute path name to 260 characters; directories can have lower limits. These limits increase to about 32K if you use absolute paths with the special '\\?\' prefix. Teach Support\Windows\Path.inc to use that prefix as needed. TODO: Other parts of Support could also learn to use this prefix. llvm-svn: 221841
* Revert 220932.Jiangning Liu2014-11-051-24/+0
| | | | | | | | | 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
* Remove FindProgramByName. NFC.Rafael Espindola2014-11-041-39/+0
| | | | llvm-svn: 221258
* Fix Visual C++ warning, Program.inc(85): warning C4018: '<' : ↵Yaron Keren2014-11-041-1/+1
| | | | | | signed/unsigned mismatch. llvm-svn: 221252
* sys::findProgramByName(): [Win32] Tweak to pass lowercase .exe to ↵NAKAMURA Takumi2014-11-041-0/+1
| | | | | | | | | SearchPath() to appease clang Driver's tests. It seems SearchPath() doesn't show actual extension on the filesystem. FIXME: Shall we use FindFirstFile() here? llvm-svn: 221246
* #include <winbase.h> is not enough for Visual C++ 2013, it errors:Yaron Keren2014-11-041-1/+1
| | | | | | | | | | | | 1>C:\Program Files (x86)\Windows Kits\8.1\Include\um\minwinbase.h(46): error C2146: syntax error : missing ';' before identifier 'nLength' 1>C:\Program Files (x86)\Windows Kits\8.1\Include\um\minwinbase.h(46): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ... including <windows.h> is actually required. llvm-svn: 221244
* [Support][Program] Add findProgramByName(Name, OptionalPaths)Michael J. Spencer2014-11-041-0/+64
| | | | llvm-svn: 221220
* Speculative fix for Windows build after r220932Hans Wennborg2014-10-301-0/+5
| | | | llvm-svn: 220936
* Removing the static initializer in ManagedStatic.cpp by using llvm_call_once ↵Chris Bieneman2014-10-301-0/+19
| | | | | | | | | | | | | | | | | | | to initialize the ManagedStatic mutex. 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
* PR21202: Memory leak in Windows RWMutexImpl when using SRWLOCKDavid Blaikie2014-10-211-5/+3
| | | | llvm-svn: 220251
* Support: Don't call close again if we get EINTRDavid Majnemer2014-10-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support: Add a utility to remap std{in,out,err} to /dev/null if closedDavid Majnemer2014-10-061-0/+4
| | | | | | | | | | | | | | | 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
* clang-format of ChangeStdinToBinary & ChangeStdoutToBinary.Yaron Keren2014-09-261-4/+4
| | | | llvm-svn: 218547
* Windows/Host.inc: Reformat the header to fit 80-col.NAKAMURA Takumi2014-09-241-1/+1
| | | | llvm-svn: 218374
* Windows/DynamicLibrary.inc: Remove 'extern "C"' in ELM_Callback.NAKAMURA Takumi2014-09-231-1/+1
| | | | | | 'extern "C" static' is not accepted by g++-4.7. Rather to tweak, I just removed 'extern "C"', since it doesn't affect the ABI. llvm-svn: 218290
* In this callback ModuleName includes the file path.Yaron Keren2014-09-221-26/+5
| | | | | | | | | | | | | | | Comparing ModuleName to the file names listed will always fail. I wonder how this code ever worked and what its purpose was. Why exclude the msvc runtime DLLs but not exclude all Windows system DLLs? Anyhow, it does not function as intended. clang-formatted as well. llvm-svn: 218276
* Misc cleanups to the FileSytem api.Rafael Espindola2014-09-111-33/+13
| | | | | | | | | | | | | | | | 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
* Add writeFileWithSystemEncoding to LibLLVMSuppor.Rafael Espindola2014-09-033-4/+65
| | | | | | | | | | | | | | | | | | | | 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
* Merge TempDir and system_temp_directory.Rafael Espindola2014-08-261-17/+45
| | | | | | | | | 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
* Refactor argument serialization logic when executing process. NFC.Rafael Espindola2014-08-251-13/+17
| | | | | | | | | | | | This patch refactors the argument serialization logic used in the Execute function, used to launch new Windows processes. There is a critical step that joins char** arguments into a single string, building the command line used to launch the new process, and the readability of this code is improved if this part is refactored in its own helper function. Patch by Rafael Auler! llvm-svn: 216411
* Remove dead code. Fixes pr20544.Rafael Espindola2014-08-081-5/+0
| | | | llvm-svn: 215243
* Windows: Don't wildcard expand /? or -?Hans Wennborg2014-07-241-0/+5
| | | | | | | Even if there's a file called c:\a, we want /? to be preserved as an option, not expanded to a filename. llvm-svn: 213894
* Perform wildcard expansion in Process::GetArgumentVector on Windows (PR17098)Hans Wennborg2014-07-161-19/+71
| | | | | | | | | | | | | | On Windows, wildcard expansion isn't performed by the shell, but left to the program itself. The common way to do this is to link with setargv.obj, which performs the expansion on argc/argv before main is entered. However, we don't use argv in Clang on Windows, but instead call GetCommandLineW so we can handle unicode arguments. This means we have to do wildcard expansion ourselves. A test case will be added on the Clang side. Differential Revision: http://reviews.llvm.org/D4529 llvm-svn: 213114
* Fix a -Wunused-local-typedefs warningAlp Toker2014-07-141-1/+1
| | | | llvm-svn: 213002
* Finishing touch for the std::error_code transition.Rafael Espindola2014-06-131-7/+7
| | | | | | | | | | | 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
* Fix build on windows.Rafael Espindola2014-06-131-84/+89
| | | | llvm-svn: 210873
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-133-28/+25
| | | | llvm-svn: 210871
* Try to fix the windows build.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210837
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-123-1/+3
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Trying to fix the windows build.Rafael Espindola2014-06-121-4/+3
| | | | llvm-svn: 210805
* Remove system_error.h.Rafael Espindola2014-06-121-1/+1
| | | | | | | This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
* Replace llvm::error_code with std::error_code.Rafael Espindola2014-06-121-4/+4
| | | | llvm-svn: 210783
* Don't import make_error_code into the llvm namespace.Rafael Espindola2014-06-121-4/+4
| | | | llvm-svn: 210772
* Prefix generic_category with std::.Rafael Espindola2014-06-121-2/+2
| | | | | | Sorry I missed these before. llvm-svn: 210740
* Don't put generic_category in the llvm namespace.Rafael Espindola2014-06-121-2/+2
| | | | llvm-svn: 210737
* Used mapWindowsError. I missed these in the initial transition.Rafael Espindola2014-06-121-3/+4
| | | | llvm-svn: 210729
* Implement get_magic with generic tools and inline it.Rafael Espindola2014-06-111-42/+0
| | | | llvm-svn: 210716
* Use std::error_code instead of llvm::error_code.Rafael Espindola2014-06-113-150/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove windows_error.Rafael Espindola2014-06-112-30/+40
| | | | | | | | | | MSVC doesn't seem to provide any is_error_code_enum enumeration for the windows errors. Fortunately very few places in llvm have to handle raw windows errors, so we can just construct the corresponding error_code directly. llvm-svn: 210631
* Process::GetRandomNumber(): fix insecure RNGAlp Toker2014-06-031-2/+3
| | | | | | | This could have generated non-random output under error conditions in release builds. llvm-svn: 210065
* Fix windows build.Rafael Espindola2014-05-312-3/+2
| | | | llvm-svn: 209961
* Turn errc and windows_error into enum classes.Rafael Espindola2014-05-311-2/+2
| | | | llvm-svn: 209957
* Use error_code() instead of error_code::succes()Rafael Espindola2014-05-313-33/+33
| | | | | | | There is no std::error_code::success, so this removes much of the noise in transitioning to std::error_code. llvm-svn: 209952
* delete dead code.Rafael Espindola2014-05-311-11/+0
| | | | llvm-svn: 209938
* Clean up language and grammar.Eric Christopher2014-05-201-1/+1
| | | | | | | Based on a patch by jfcaron3@gmail.com! PR19806 llvm-svn: 209216
* MemoryBuffer: Use GetNativeSystemInfo()Alp Toker2014-05-191-8/+6
| | | | | | | Removes old 4096 byte workaround. This functionality has been available since Windows XP. llvm-svn: 209137
* Use raw_ostream and Format.h on Windows so that we don't have to rollChandler Carruth2014-04-281-5/+10
| | | | | | our own portability system to cope without snprintf. llvm-svn: 207389
* Update the Windows TimeValue formatting to match the new formatting onChandler Carruth2014-04-281-9/+5
| | | | | | Unix-like OSes. llvm-svn: 207388
* Windows: canonicalise the default windows tripleSaleem Abdulrasool2014-03-291-1/+1
| | | | | | | Canonicalise the default triple that is used on Windows. This should hopefully fix the MSVC buildbots. llvm-svn: 205070
* support: add a utility function to normalise path separatorsSaleem Abdulrasool2014-03-111-0/+5
| | | | | | | | 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
OpenPOWER on IntegriCloud