summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows/Process.inc
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Windows] Simplify WindowsSupport.hReid Kleckner2018-11-061-0/+24
| | | | | | | | | | | | | | | | | Sink Windows version detection code from WindowsSupport.h to Path.inc. These functions don't need to be inlined. I randomly picked Process.inc for the Windows version helpers, since that's the most related file. Sink MakeErrMsg to Program.inc since it's the main client. Move those functions into the llvm namespace, and delete the scoped handle copy and assignment operators. Reviewers: zturner, aganea Differential Revision: https://reviews.llvm.org/D54182 llvm-svn: 346280
* [Support] Avoid calling CommandLineToArgvW from shell32.dllReid Kleckner2018-09-111-55/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Shell32.dll depends on gdi32.dll and user32.dll, which are mostly DLLs for Windows GUI functionality. LLVM's utilities don't typically need GUI functionality, and loading these DLLs seems to be slowing down startup. Also, we already have an implementation of Windows command line tokenization in cl::TokenizeWindowsCommandLine, so we can just use it. The goal is to get the original argv in UTF-8, so that it can pass through most LLVM string APIs. A Windows process starts life with a UTF-16 string for its command line, and it can be retreived with GetCommandLineW from kernel32.dll. Previously, we would: 1. Get the wide command line 2. Call CommandLineToArgvW to handle quoting rules and separate it into arguments. 3. For each wide argument, expand wildcards (* and ?) using FindFirstFileW. 4. Convert each argument to UTF-8 Now we: 1. Get the wide command line, convert the whole thing to UTF-8 2. Tokenize the UTF-8 command line with cl::TokenizeWindowsCommandLine 3. For each argument, expand wildcards if present - This requires converting back to UTF-16 to call FindFirstFileW - Results of FindFirstFileW must be converted back to UTF-8 Reviewers: zturner Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51941 llvm-svn: 341988
* Set console mode when -fansi-escape-codes is enabled David Bolvansky2018-09-041-0/+9
| | | | | | | | | | | | | | | | | | | | | Summary: Windows console now supports supports ANSI escape codes, but we need to enable it using SetConsoleMode with ENABLE_VIRTUAL_TERMINAL_PROCESSING flag. Fixes https://bugs.llvm.org/show_bug.cgi?id=38817 Tested on Windows 10, screenshot: https://i.imgur.com/bqYq0Uy.png Reviewers: zturner, chandlerc Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51611 llvm-svn: 341396
* Do not enforce absolute path argv0 in windowsHans Wennborg2018-06-131-29/+39
| | | | | | | | | | | | | | | | Even if we support no-canonical-prefix on clang-cl(https://reviews.llvm.org/D47480), argv0 becomes absolute path in clang-cl and that embeds absolute path in /showIncludes. This patch removes such full path normalization from InitLLVM on windows, and that removes absolute path from clang-cl output (obj/stdout/stderr) when debug flag is disabled. Patch by Takuto Ikuta! Differential Revision https://reviews.llvm.org/D47578 llvm-svn: 334602
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-011-0/+1
| | | | | | | | | | | | | | | | | | The idea behind WindowsSupport.h is that it's in the source directory so that windows.h'isms don't leak out into the larger LLVM project. To that end, any symbol that references a symbol from windows.h must be in this private header, and not in a public header. However, we had some useful utility functions in WindowsSupport.h which have no dependency on the Windows API, but still only make sense on Windows. Those functions should be usable outside of Support since there is no risk of causing a windows.h leak. Although this introduces some preprocessor logic in some header files, It's not too egregious and it's better than the alternative of duplicating a ton of code. Differential Revision: https://reviews.llvm.org/D47662 llvm-svn: 333798
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-1/+1
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* Rename sys::Process::GetArgumentVector -> sys::windows::GetCommandLineArgumentsRui Ueyama2018-04-171-27/+25
| | | | | | | | | | | | | | GetArgumentVector (or GetCommandLineArguments) is very Windows-specific. I think it doesn't make much sense to provide that function from sys::Process. I also made a change so that the function takes a BumpPtrAllocator instead of a SpecificBumpPtrAllocator. The latter is the class to call dtors, but since char * is trivially destructible, we should use the former class. Differential Revision: https://reviews.llvm.org/D45641 llvm-svn: 330216
* Remove HAVE_LIBPSAPI, HAVE_SHELL32.Nico Weber2018-04-021-8/+1
| | | | | | | | | | These used to be set in the old autoconf build, but the cmake build has had a "TODO: actually check for these" comment since it was checked in, and they were set to 1 on mingw unconditionally. It seems safe to say that they always exist under mingw, so just remove them and assume they're set exactly when on mingw (with msvc, we use `pragma comment` instead of linking these via flags). llvm-svn: 328992
* [Support] env vars with empty values on windowsBen Dunbobbin2017-08-181-2/+3
| | | | | | | | | | | | | | | | An environment variable can be in one of three states: 1. undefined. 2. defined with a non-empty value. 3. defined but with an empty value. The windows implementation did not support case 3 (it was not handling errors). The Linux implementation is already correct. Differential Revision: https://reviews.llvm.org/D36394 llvm-svn: 311174
* Do not pollute the namespace in a header file.Kristof Beyls2017-03-311-1/+0
| | | | llvm-svn: 299218
* Remove TimeValue usage from llvm/SupportPavel Labath2016-10-241-17/+5
| | | | | | | | | | | | | | | | | Summary: This is a follow-up to D25416. It removes all usages of TimeValue from llvm/Support library (except for the actual TimeValue declaration), and replaces them with appropriate usages of std::chrono. To facilitate this, I have added small utility functions for converting time points and durations into appropriate OS-specific types (FILETIME, struct timespec, ...). Reviewers: zturner, mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25730 llvm-svn: 284966
* Properly handle short file names on the command line in Windows [TAKE 2]Adrian McCarthy2016-06-201-2/+34
| | | | | | | | Trying to expand short names with a relative path doesn't work, so this first gets the module name to get a full path (which can still have short names). llvm-svn: 273171
* Revert "Properly handle short file names on the command line in Windows"Adrian McCarthy2016-06-171-27/+2
| | | | | | This reverts commit 3e5651782cfc985fca9d94595cad63059e587e2f. llvm-svn: 273033
* Properly handle short file names on the command line in WindowsAdrian McCarthy2016-06-161-2/+27
| | | | | | | | Some build systems use the short (8.3) file names on Windows, especially if the path has spaces in it. The shortening made it impossible for clang to distinguish between clang.exe, clang++.exe, and clang-cl.exe. So this expands short names in the first argument and does wildcard expansion for the rest. Differential Revision: http://reviews.llvm.org/D21420 llvm-svn: 272967
* [Support] Creation of minidump after compiler crash on WindowsLeny Kholodov2016-05-041-0/+2
| | | | | | | | | | | In the current implementation compiler only prints stack trace to console after crash. This patch adds saving of minidump files which contain a useful subset of the information for further debugging. Differential Revision: http://reviews.llvm.org/D18216 llvm-svn: 268519
* Report Windows error code in a fatal error after a system call.Paul Robinson2015-11-111-2/+9
| | | | llvm-svn: 252800
* Replace windows_error calls with mapWindowsError.Yaron Keren2015-05-041-5/+1
| | | | | | | | After r210687, windows_error does nothing but call mapWindowsError. Other Windows/*.inc files directly call mapWindowsError. This patch updates Path.inc and Process.inc to do the same. llvm-svn: 236409
* [raw_ostream] When printing color on Windows, use correct bg color.Zachary Turner2015-02-281-0/+13
| | | | | | | | | | | | | | | | | | | When using SetConsoleTextAttribute() to set the foreground or background color, if you don't explicitly set both colors, then a default value of black will be chosen for whichever you don't specify a value for. This is annoying when you have a non default console background color, for example, and you try to set the foreground color. This patch gets the existing fg/bg color and when you set one attribute, sets the opposite attribute to its existing color prior to comitting the update. Reviewed by: Aaron Ballman Differential Revision: http://reviews.llvm.org/D7967 llvm-svn: 230859
* Remove dead code. NFC.Rafael Espindola2014-12-041-27/+4
| | | | | | This interface was added 2 years ago but users never developed. llvm-svn: 223368
* 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
* 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
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-131-5/+4
| | | | llvm-svn: 210871
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-121-1/+1
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Use std::error_code instead of llvm::error_code.Rafael Espindola2014-06-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-111-0/+4
| | | | | | | | | | 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
* Use error_code() instead of error_code::succes()Rafael Espindola2014-05-311-1/+1
| | | | | | | There is no std::error_code::success, so this removes much of the noise in transitioning to std::error_code. llvm-svn: 209952
* 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
* Remove unnecessary variables.Ahmed Charles2014-03-051-2/+2
| | | | | | Found self-hosting clang-cl on windows. :) llvm-svn: 202935
* Rename Windows.h to WindowsSupport.h to avoid ambiguityReid Kleckner2014-02-121-1/+1
| | | | llvm-svn: 201258
* Hopefully fixing the MinGW 32 build, which was broken by r200767. Not using ↵Aaron Ballman2014-02-111-4/+11
| | | | | | rand_s() since MinGW does not have an implementation for it, but instead using the underlying CryptGenRandom APIs. llvm-svn: 201124
* Try to unbreak the mingw32 build.Benjamin Kramer2014-02-071-1/+1
| | | | llvm-svn: 200973
* Implemented support for Process::GetRandomNumber on Windows.Aaron Ballman2014-02-041-0/+7
| | | | | | Patch thanks to Stephan Tolksdorf! llvm-svn: 200767
* Try to fix the windows build. The comments in other files don't seem toChandler Carruth2014-01-071-4/+5
| | | | | | be quite accurate. =] llvm-svn: 198690
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-2/+3
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* Windows: Avoiding resizing, use uninitialized data() insteadDavid Majnemer2013-10-071-4/+5
| | | | | | This is ever-so faster but more importantly matches what we have elsewhere. llvm-svn: 192137
* Windows/Process.inc: Fix for +Asserts. &Buf[0] is not guaranteed if size is ↵NAKAMURA Takumi2013-10-071-1/+1
| | | | | | zero. llvm-svn: 192103
* Revert "Revert "Windows: Add support for unicode command lines""David Majnemer2013-10-071-11/+51
| | | | | | | This reverts commit r192070 which reverted r192069, I forgot to regenerate the configure scripts. llvm-svn: 192079
* Revert "Windows: Add support for unicode command lines"David Majnemer2013-10-061-52/+12
| | | | | | | This is causing MinGW bots to fail. This reverts commit r192069. llvm-svn: 192070
* Windows: Add support for unicode command linesDavid Majnemer2013-10-061-12/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVCRT deliberately sends main() code-page specific characters. This isn't too useful to LLVM as we end up converting the arguments to UTF-16 and subsequently attempt to use the result as, for example, a file name. Instead, we need to have the ability to access the Unicode command line and transform it to UTF-8. This has the distinct advantage over using the MSVC-specific wmain() function as our entry point because: - It doesn't work on cygwin. - It only work on MinGW with caveats and only then on certain versions. - We get to keep our entry point as main(). :) N.B. This patch includes fixes to other parts of lib/Support/Windows s.t. we would be able to take advantage of getting the Unicode paths. E.G. clang spawning clang -cc1 would want to give it Unicode arguments. Reviewers: aaron.ballman, Bigcheese, rnk, ruiu Reviewed By: rnk CC: llvm-commits, ygao Differential Revision: http://llvm-reviews.chandlerc.com/D1834 llvm-svn: 192069
* Support ANSI escape code on WindowsNico Rieck2013-09-111-1/+13
| | | | | | | | In some cases (e.g. when a build system pipes stderr) the Windows console API cannot be used to color output. For these, provide a way to switch to ANSI escape codes. This is required for Clang's -fansi-escape-codes option. llvm-svn: 190460
* Add getenv() wrapper that works on multibyte environment variable.Rui Ueyama2013-09-101-0/+30
| | | | | | | | | | | | | | | | | | On Windows, character encoding of multibyte environment variable varies depending on settings. The only reliable way to handle it I think is to use GetEnvironmentVariableW(). GetEnvironmentVariableW() works on wchar_t string, which is on Windows UTF16 string. That's not ideal because we use UTF-8 as the internal encoding in LLVM. This patch defines a wrapper function which takes and returns UTF-8 string for GetEnvironmentVariableW(). The wrapper function does not do any conversion and just forwards the argument to getenv() on Unix. Differential Revision: http://llvm-reviews.chandlerc.com/D1612 llvm-svn: 190423
* Support/Process: Add comments about PageSize and AllocationGranularity on ↵NAKAMURA Takumi2013-09-041-0/+2
| | | | | | Cygwin and Win32. llvm-svn: 189940
* Removing unused functionality.Aaron Ballman2013-08-161-10/+0
| | | | llvm-svn: 188565
* Updating function comments; no functional changes intended.Aaron Ballman2013-08-161-5/+12
| | | | llvm-svn: 188554
* sys::process::get_id() now returns the process ID instead of a process ↵Aaron Ballman2013-06-081-1/+1
| | | | | | handle on Windows. Patch thanks to Kim Gräsman! llvm-svn: 183621
* Fix an obvious typo spotted by Reid Kleckner, and breaking windows builds.Chandler Carruth2013-01-041-1/+1
| | | | llvm-svn: 171559
OpenPOWER on IntegriCloud