2004-09-15 13:47:40 +08:00
|
|
|
//===- Win32/Process.cpp - Win32 Process Implementation ------- -*- C++ -*-===//
|
2010-11-30 02:16:10 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-11-30 02:16:10 +08:00
|
|
|
//
|
2004-09-15 13:47:40 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file provides the Win32 specific implementation of the Process class.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-10-07 09:00:07 +08:00
|
|
|
#include "llvm/Support/Allocator.h"
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2018-06-02 06:23:46 +08:00
|
|
|
#include "llvm/Support/ConvertUTF.h"
|
2014-06-03 11:01:03 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
#include "llvm/Support/StringSaver.h"
|
2014-06-12 03:05:50 +08:00
|
|
|
#include "llvm/Support/WindowsError.h"
|
2014-01-07 20:37:13 +08:00
|
|
|
#include <malloc.h>
|
|
|
|
|
|
|
|
// The Windows.h header must be after LLVM and standard headers.
|
2020-02-28 16:59:24 +08:00
|
|
|
#include "llvm/Support/Windows/WindowsSupport.h"
|
2014-01-07 20:37:13 +08:00
|
|
|
|
2011-09-24 07:23:36 +08:00
|
|
|
#include <direct.h>
|
2012-12-04 00:50:05 +08:00
|
|
|
#include <io.h>
|
|
|
|
#include <psapi.h>
|
2013-10-07 09:00:07 +08:00
|
|
|
#include <shellapi.h>
|
2004-12-20 11:24:56 +08:00
|
|
|
|
2018-04-03 01:32:48 +08:00
|
|
|
#if !defined(__MINGW32__)
|
2013-10-07 04:44:34 +08:00
|
|
|
#pragma comment(lib, "psapi.lib")
|
2013-10-07 09:00:07 +08:00
|
|
|
#pragma comment(lib, "shell32.lib")
|
2006-06-02 03:03:21 +08:00
|
|
|
#endif
|
2004-09-15 13:47:40 +08:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
2010-11-30 02:16:10 +08:00
|
|
|
//=== WARNING: Implementation here must contain only Win32 specific code
|
2004-09-15 13:47:40 +08:00
|
|
|
//=== and must not be UNIX code
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2005-02-19 11:01:13 +08:00
|
|
|
#ifdef __MINGW32__
|
2004-12-23 11:44:40 +08:00
|
|
|
// This ban should be lifted when MinGW 1.0+ has defined this value.
|
|
|
|
# define _HEAPOK (-2)
|
|
|
|
#endif
|
|
|
|
|
2012-12-31 19:45:20 +08:00
|
|
|
using namespace llvm;
|
2012-12-31 19:17:50 +08:00
|
|
|
|
2020-04-13 19:26:35 +08:00
|
|
|
Process::Pid Process::getProcessId() {
|
|
|
|
static_assert(sizeof(Pid) >= sizeof(DWORD),
|
|
|
|
"Process::Pid should be big enough to store DWORD");
|
|
|
|
return Pid(::GetCurrentProcessId());
|
|
|
|
}
|
|
|
|
|
2014-05-20 00:13:28 +08:00
|
|
|
// This function retrieves the page size using GetNativeSystemInfo() and is
|
|
|
|
// present solely so it can be called once to initialize the self_process member
|
|
|
|
// below.
|
2014-12-05 00:59:36 +08:00
|
|
|
static unsigned computePageSize() {
|
2014-05-20 00:13:28 +08:00
|
|
|
// GetNativeSystemInfo() provides the physical page size which may differ
|
|
|
|
// from GetSystemInfo() in 32-bit applications running under WOW64.
|
2004-09-15 13:47:40 +08:00
|
|
|
SYSTEM_INFO info;
|
2014-05-20 00:13:28 +08:00
|
|
|
GetNativeSystemInfo(&info);
|
2013-09-04 22:12:26 +08:00
|
|
|
// FIXME: FileOffset in MapViewOfFile() should be aligned to not dwPageSize,
|
|
|
|
// but dwAllocationGranularity.
|
2004-09-15 13:47:40 +08:00
|
|
|
return static_cast<unsigned>(info.dwPageSize);
|
|
|
|
}
|
|
|
|
|
2019-05-08 10:11:07 +08:00
|
|
|
Expected<unsigned> Process::getPageSize() {
|
2014-12-05 00:59:36 +08:00
|
|
|
static unsigned Ret = computePageSize();
|
|
|
|
return Ret;
|
2004-09-15 13:47:40 +08:00
|
|
|
}
|
|
|
|
|
2010-11-30 02:16:10 +08:00
|
|
|
size_t
|
2004-12-20 08:59:28 +08:00
|
|
|
Process::GetMallocUsage()
|
|
|
|
{
|
2004-12-20 11:24:56 +08:00
|
|
|
_HEAPINFO hinfo;
|
|
|
|
hinfo._pentry = NULL;
|
|
|
|
|
|
|
|
size_t size = 0;
|
|
|
|
|
|
|
|
while (_heapwalk(&hinfo) == _HEAPOK)
|
|
|
|
size += hinfo._size;
|
|
|
|
|
|
|
|
return size;
|
2004-12-20 08:59:28 +08:00
|
|
|
}
|
|
|
|
|
2016-10-24 18:59:17 +08:00
|
|
|
void Process::GetTimeUsage(TimePoint<> &elapsed, std::chrono::nanoseconds &user_time,
|
|
|
|
std::chrono::nanoseconds &sys_time) {
|
|
|
|
elapsed = std::chrono::system_clock::now();;
|
2004-12-20 08:59:28 +08:00
|
|
|
|
2013-01-05 07:19:55 +08:00
|
|
|
FILETIME ProcCreate, ProcExit, KernelTime, UserTime;
|
|
|
|
if (GetProcessTimes(GetCurrentProcess(), &ProcCreate, &ProcExit, &KernelTime,
|
|
|
|
&UserTime) == 0)
|
|
|
|
return;
|
2004-12-20 08:59:28 +08:00
|
|
|
|
2016-10-24 18:59:17 +08:00
|
|
|
user_time = toDuration(UserTime);
|
|
|
|
sys_time = toDuration(KernelTime);
|
2004-12-20 08:59:28 +08:00
|
|
|
}
|
|
|
|
|
2004-12-27 14:17:27 +08:00
|
|
|
// Some LLVM programs such as bugpoint produce core files as a normal part of
|
2013-08-16 22:33:07 +08:00
|
|
|
// their operation. To prevent the disk from filling up, this configuration
|
|
|
|
// item does what's necessary to prevent their generation.
|
2004-12-27 14:17:27 +08:00
|
|
|
void Process::PreventCoreFiles() {
|
2013-08-16 22:33:07 +08:00
|
|
|
// Windows does have the concept of core files, called minidumps. However,
|
|
|
|
// disabling minidumps for a particular application extends past the lifetime
|
|
|
|
// of that application, which is the incorrect behavior for this API.
|
|
|
|
// Additionally, the APIs require elevated privileges to disable and re-
|
|
|
|
// enable minidumps, which makes this untenable. For more information, see
|
|
|
|
// WerAddExcludedApplication and WerRemoveExcludedApplication (Vista and
|
|
|
|
// later).
|
|
|
|
//
|
|
|
|
// Windows also has modal pop-up message boxes. As this method is used by
|
|
|
|
// bugpoint, preventing these pop-ups is additionally important.
|
2005-02-18 15:05:18 +08:00
|
|
|
SetErrorMode(SEM_FAILCRITICALERRORS |
|
|
|
|
SEM_NOGPFAULTERRORBOX |
|
|
|
|
SEM_NOOPENFILEERRORBOX);
|
2016-05-05 00:56:51 +08:00
|
|
|
|
|
|
|
coreFilesPrevented = true;
|
2004-12-27 14:17:27 +08:00
|
|
|
}
|
|
|
|
|
2013-09-11 03:45:51 +08:00
|
|
|
/// Returns the environment variable \arg Name's value as a string encoded in
|
|
|
|
/// UTF-8. \arg Name is assumed to be in UTF-8 encoding.
|
|
|
|
Optional<std::string> Process::GetEnv(StringRef Name) {
|
|
|
|
// Convert the argument to UTF-16 to pass it to _wgetenv().
|
|
|
|
SmallVector<wchar_t, 128> NameUTF16;
|
2014-03-05 13:04:00 +08:00
|
|
|
if (windows::UTF8ToUTF16(Name, NameUTF16))
|
2013-09-11 03:45:51 +08:00
|
|
|
return None;
|
|
|
|
|
|
|
|
// Environment variable can be encoded in non-UTF8 encoding, and there's no
|
|
|
|
// way to know what the encoding is. The only reliable way to look up
|
|
|
|
// multibyte environment variable is to use GetEnvironmentVariableW().
|
2013-10-07 09:00:07 +08:00
|
|
|
SmallVector<wchar_t, MAX_PATH> Buf;
|
|
|
|
size_t Size = MAX_PATH;
|
|
|
|
do {
|
2013-10-08 05:57:07 +08:00
|
|
|
Buf.reserve(Size);
|
2017-08-19 00:55:44 +08:00
|
|
|
SetLastError(NO_ERROR);
|
2013-10-08 05:57:07 +08:00
|
|
|
Size =
|
2017-08-19 00:55:44 +08:00
|
|
|
GetEnvironmentVariableW(NameUTF16.data(), Buf.data(), Buf.capacity());
|
|
|
|
if (Size == 0 && GetLastError() == ERROR_ENVVAR_NOT_FOUND)
|
2013-10-07 09:00:07 +08:00
|
|
|
return None;
|
|
|
|
|
2013-09-11 03:45:51 +08:00
|
|
|
// Try again with larger buffer.
|
2013-10-07 09:00:07 +08:00
|
|
|
} while (Size > Buf.capacity());
|
|
|
|
Buf.set_size(Size);
|
2013-09-11 03:45:51 +08:00
|
|
|
|
|
|
|
// Convert the result from UTF-16 to UTF-8.
|
2013-10-07 09:00:07 +08:00
|
|
|
SmallVector<char, MAX_PATH> Res;
|
2014-03-05 13:04:00 +08:00
|
|
|
if (windows::UTF16ToUTF8(Buf.data(), Size, Res))
|
2013-09-11 03:45:51 +08:00
|
|
|
return None;
|
2013-10-08 05:57:07 +08:00
|
|
|
return std::string(Res.data());
|
2013-09-11 03:45:51 +08:00
|
|
|
}
|
|
|
|
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
/// Perform wildcard expansion of Arg, or just push it into Args if it doesn't
|
|
|
|
/// have wildcards or doesn't match any files.
|
|
|
|
static std::error_code WildcardExpand(StringRef Arg,
|
2018-04-18 05:09:16 +08:00
|
|
|
SmallVectorImpl<const char *> &Args,
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
StringSaver &Saver) {
|
|
|
|
std::error_code EC;
|
2014-07-16 08:52:11 +08:00
|
|
|
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
// Don't expand Arg if it does not contain any wildcard characters. This is
|
|
|
|
// the common case. Also don't wildcard expand /?. Always treat it as an
|
|
|
|
// option.
|
|
|
|
if (Arg.find_first_of("*?") == StringRef::npos || Arg == "/?" ||
|
|
|
|
Arg == "-?") {
|
|
|
|
Args.push_back(Arg.data());
|
|
|
|
return EC;
|
2014-07-25 05:09:45 +08:00
|
|
|
}
|
|
|
|
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
// Convert back to UTF-16 so we can call FindFirstFileW.
|
|
|
|
SmallVector<wchar_t, MAX_PATH> ArgW;
|
|
|
|
EC = windows::UTF8ToUTF16(Arg, ArgW);
|
|
|
|
if (EC)
|
|
|
|
return EC;
|
2014-07-16 08:52:11 +08:00
|
|
|
|
|
|
|
// Search for matching files.
|
2016-06-21 01:51:27 +08:00
|
|
|
// FIXME: This assumes the wildcard is only in the file name and not in the
|
|
|
|
// directory portion of the file path. For example, it doesn't handle
|
|
|
|
// "*\foo.c" nor "s?c\bar.cpp".
|
2014-07-16 08:52:11 +08:00
|
|
|
WIN32_FIND_DATAW FileData;
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
HANDLE FindHandle = FindFirstFileW(ArgW.data(), &FileData);
|
2014-07-16 08:52:11 +08:00
|
|
|
if (FindHandle == INVALID_HANDLE_VALUE) {
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
Args.push_back(Arg.data());
|
|
|
|
return EC;
|
2014-07-16 08:52:11 +08:00
|
|
|
}
|
|
|
|
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
// Extract any directory part of the argument.
|
|
|
|
SmallString<MAX_PATH> Dir = Arg;
|
|
|
|
sys::path::remove_filename(Dir);
|
|
|
|
const int DirSize = Dir.size();
|
|
|
|
|
2014-07-16 08:52:11 +08:00
|
|
|
do {
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
SmallString<MAX_PATH> FileName;
|
|
|
|
EC = windows::UTF16ToUTF8(FileData.cFileName, wcslen(FileData.cFileName),
|
2014-07-16 08:52:11 +08:00
|
|
|
FileName);
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
if (EC)
|
2014-07-16 08:52:11 +08:00
|
|
|
break;
|
|
|
|
|
2016-06-21 01:51:27 +08:00
|
|
|
// Append FileName to Dir, and remove it afterwards.
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
llvm::sys::path::append(Dir, FileName);
|
|
|
|
Args.push_back(Saver.save(StringRef(Dir)).data());
|
2014-07-16 08:52:11 +08:00
|
|
|
Dir.resize(DirSize);
|
|
|
|
} while (FindNextFileW(FindHandle, &FileData));
|
|
|
|
|
|
|
|
FindClose(FindHandle);
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
return EC;
|
2014-07-16 08:52:11 +08:00
|
|
|
}
|
|
|
|
|
2018-06-13 22:29:26 +08:00
|
|
|
static std::error_code GetExecutableName(SmallVectorImpl<char> &Filename) {
|
|
|
|
// The first argument may contain just the name of the executable (e.g.,
|
|
|
|
// "clang") rather than the full path, so swap it with the full path.
|
|
|
|
wchar_t ModuleName[MAX_PATH];
|
|
|
|
size_t Length = ::GetModuleFileNameW(NULL, ModuleName, MAX_PATH);
|
|
|
|
if (Length == 0 || Length == MAX_PATH) {
|
|
|
|
return mapWindowsError(GetLastError());
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the first argument is a shortened (8.3) name (which is possible even
|
|
|
|
// if we got the module name), the driver will have trouble distinguishing it
|
|
|
|
// (e.g., clang.exe v. clang++.exe), so expand it now.
|
|
|
|
Length = GetLongPathNameW(ModuleName, ModuleName, MAX_PATH);
|
2016-06-21 01:51:27 +08:00
|
|
|
if (Length == 0)
|
|
|
|
return mapWindowsError(GetLastError());
|
2018-06-13 22:29:26 +08:00
|
|
|
if (Length > MAX_PATH) {
|
2016-06-21 01:51:27 +08:00
|
|
|
// We're not going to try to deal with paths longer than MAX_PATH, so we'll
|
|
|
|
// treat this as an error. GetLastError() returns ERROR_SUCCESS, which
|
|
|
|
// isn't useful, so we'll hardcode an appropriate error value.
|
|
|
|
return mapWindowsError(ERROR_INSUFFICIENT_BUFFER);
|
|
|
|
}
|
2018-06-13 22:29:26 +08:00
|
|
|
|
|
|
|
std::error_code EC = windows::UTF16ToUTF8(ModuleName, Length, Filename);
|
|
|
|
if (EC)
|
|
|
|
return EC;
|
|
|
|
|
|
|
|
StringRef Base = sys::path::filename(Filename.data());
|
|
|
|
Filename.assign(Base.begin(), Base.end());
|
|
|
|
return std::error_code();
|
2016-06-21 01:51:27 +08:00
|
|
|
}
|
|
|
|
|
2014-06-13 10:24:39 +08:00
|
|
|
std::error_code
|
2018-04-18 05:09:16 +08:00
|
|
|
windows::GetCommandLineArguments(SmallVectorImpl<const char *> &Args,
|
|
|
|
BumpPtrAllocator &Alloc) {
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
const wchar_t *CmdW = GetCommandLineW();
|
|
|
|
assert(CmdW);
|
2018-06-13 22:29:26 +08:00
|
|
|
std::error_code EC;
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
SmallString<MAX_PATH> Cmd;
|
|
|
|
EC = windows::UTF16ToUTF8(CmdW, wcslen(CmdW), Cmd);
|
|
|
|
if (EC)
|
|
|
|
return EC;
|
2016-06-21 01:51:27 +08:00
|
|
|
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
SmallVector<const char *, 20> TmpArgs;
|
|
|
|
StringSaver Saver(Alloc);
|
|
|
|
cl::TokenizeWindowsCommandLine(Cmd, Saver, TmpArgs, /*MarkEOLs=*/false);
|
2016-06-21 01:51:27 +08:00
|
|
|
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
for (const char *Arg : TmpArgs) {
|
|
|
|
EC = WildcardExpand(Arg, Args, Saver);
|
2018-06-13 22:29:26 +08:00
|
|
|
if (EC)
|
|
|
|
return EC;
|
2013-10-07 09:00:07 +08:00
|
|
|
}
|
|
|
|
|
2018-06-13 22:29:26 +08:00
|
|
|
SmallVector<char, MAX_PATH> Arg0(Args[0], Args[0] + strlen(Args[0]));
|
|
|
|
SmallVector<char, MAX_PATH> Filename;
|
|
|
|
sys::path::remove_filename(Arg0);
|
|
|
|
EC = GetExecutableName(Filename);
|
|
|
|
if (EC)
|
|
|
|
return EC;
|
|
|
|
sys::path::append(Arg0, Filename);
|
[Support] Avoid calling CommandLineToArgvW from shell32.dll
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
2018-09-12 04:22:39 +08:00
|
|
|
Args[0] = Saver.save(Arg0).data();
|
2018-06-13 22:29:26 +08:00
|
|
|
return std::error_code();
|
2013-10-07 09:00:07 +08:00
|
|
|
}
|
|
|
|
|
2014-10-07 07:16:18 +08:00
|
|
|
std::error_code Process::FixupStandardFileDescriptors() {
|
|
|
|
return std::error_code();
|
|
|
|
}
|
|
|
|
|
2014-10-07 13:48:40 +08:00
|
|
|
std::error_code Process::SafelyCloseFileDescriptor(int FD) {
|
|
|
|
if (::close(FD) < 0)
|
|
|
|
return std::error_code(errno, std::generic_category());
|
|
|
|
return std::error_code();
|
|
|
|
}
|
|
|
|
|
2005-01-02 06:54:05 +08:00
|
|
|
bool Process::StandardInIsUserInput() {
|
2009-09-12 04:46:33 +08:00
|
|
|
return FileDescriptorIsDisplayed(0);
|
2005-01-02 06:54:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Process::StandardOutIsDisplayed() {
|
2009-09-12 04:46:33 +08:00
|
|
|
return FileDescriptorIsDisplayed(1);
|
2005-01-02 06:54:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Process::StandardErrIsDisplayed() {
|
2009-09-12 04:46:33 +08:00
|
|
|
return FileDescriptorIsDisplayed(2);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Process::FileDescriptorIsDisplayed(int fd) {
|
2012-07-19 08:06:06 +08:00
|
|
|
DWORD Mode; // Unused
|
2010-11-10 16:37:47 +08:00
|
|
|
return (GetConsoleMode((HANDLE)_get_osfhandle(fd), &Mode) != 0);
|
2005-01-02 06:54:05 +08:00
|
|
|
}
|
|
|
|
|
2009-05-12 02:05:52 +08:00
|
|
|
unsigned Process::StandardOutColumns() {
|
|
|
|
unsigned Columns = 0;
|
|
|
|
CONSOLE_SCREEN_BUFFER_INFO csbi;
|
|
|
|
if (GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi))
|
|
|
|
Columns = csbi.dwSize.X;
|
|
|
|
return Columns;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned Process::StandardErrColumns() {
|
|
|
|
unsigned Columns = 0;
|
|
|
|
CONSOLE_SCREEN_BUFFER_INFO csbi;
|
|
|
|
if (GetConsoleScreenBufferInfo(GetStdHandle(STD_ERROR_HANDLE), &csbi))
|
|
|
|
Columns = csbi.dwSize.X;
|
|
|
|
return Columns;
|
|
|
|
}
|
|
|
|
|
2012-07-21 02:29:38 +08:00
|
|
|
// The terminal always has colors.
|
2012-07-21 03:49:33 +08:00
|
|
|
bool Process::FileDescriptorHasColors(int fd) {
|
2012-07-21 02:29:38 +08:00
|
|
|
return FileDescriptorIsDisplayed(fd);
|
2009-06-04 15:09:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Process::StandardOutHasColors() {
|
2012-07-21 02:29:38 +08:00
|
|
|
return FileDescriptorHasColors(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Process::StandardErrHasColors() {
|
|
|
|
return FileDescriptorHasColors(2);
|
2009-06-04 15:09:50 +08:00
|
|
|
}
|
2009-06-04 16:18:25 +08:00
|
|
|
|
2013-09-11 08:36:48 +08:00
|
|
|
static bool UseANSI = false;
|
|
|
|
void Process::UseANSIEscapeCodes(bool enable) {
|
2018-09-05 03:23:05 +08:00
|
|
|
#if defined(ENABLE_VIRTUAL_TERMINAL_PROCESSING)
|
|
|
|
if (enable) {
|
|
|
|
HANDLE Console = GetStdHandle(STD_OUTPUT_HANDLE);
|
|
|
|
DWORD Mode;
|
|
|
|
GetConsoleMode(Console, &Mode);
|
|
|
|
Mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
|
|
|
|
SetConsoleMode(Console, Mode);
|
|
|
|
}
|
|
|
|
#endif
|
2013-09-11 08:36:48 +08:00
|
|
|
UseANSI = enable;
|
|
|
|
}
|
|
|
|
|
2009-06-04 15:09:50 +08:00
|
|
|
namespace {
|
|
|
|
class DefaultColors
|
|
|
|
{
|
|
|
|
private:
|
|
|
|
WORD defaultColor;
|
|
|
|
public:
|
|
|
|
DefaultColors()
|
|
|
|
:defaultColor(GetCurrentColor()) {}
|
|
|
|
static unsigned GetCurrentColor() {
|
|
|
|
CONSOLE_SCREEN_BUFFER_INFO csbi;
|
|
|
|
if (GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi))
|
|
|
|
return csbi.wAttributes;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
WORD operator()() const { return defaultColor; }
|
|
|
|
};
|
|
|
|
|
|
|
|
DefaultColors defaultColors;
|
2015-03-01 03:08:27 +08:00
|
|
|
|
|
|
|
WORD fg_color(WORD color) {
|
|
|
|
return color & (FOREGROUND_BLUE | FOREGROUND_GREEN |
|
|
|
|
FOREGROUND_INTENSITY | FOREGROUND_RED);
|
|
|
|
}
|
|
|
|
|
|
|
|
WORD bg_color(WORD color) {
|
|
|
|
return color & (BACKGROUND_BLUE | BACKGROUND_GREEN |
|
|
|
|
BACKGROUND_INTENSITY | BACKGROUND_RED);
|
|
|
|
}
|
2009-06-04 15:09:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Process::ColorNeedsFlush() {
|
2013-09-11 08:36:48 +08:00
|
|
|
return !UseANSI;
|
2009-06-04 15:09:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *Process::OutputBold(bool bg) {
|
2013-09-11 08:36:48 +08:00
|
|
|
if (UseANSI) return "\033[1m";
|
|
|
|
|
2009-06-04 15:09:50 +08:00
|
|
|
WORD colors = DefaultColors::GetCurrentColor();
|
|
|
|
if (bg)
|
|
|
|
colors |= BACKGROUND_INTENSITY;
|
|
|
|
else
|
|
|
|
colors |= FOREGROUND_INTENSITY;
|
|
|
|
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), colors);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *Process::OutputColor(char code, bool bold, bool bg) {
|
2013-09-11 08:36:48 +08:00
|
|
|
if (UseANSI) return colorcodes[bg?1:0][bold?1:0][code&7];
|
|
|
|
|
2015-03-01 03:08:27 +08:00
|
|
|
WORD current = DefaultColors::GetCurrentColor();
|
2009-06-04 15:09:50 +08:00
|
|
|
WORD colors;
|
|
|
|
if (bg) {
|
|
|
|
colors = ((code&1) ? BACKGROUND_RED : 0) |
|
|
|
|
((code&2) ? BACKGROUND_GREEN : 0 ) |
|
|
|
|
((code&4) ? BACKGROUND_BLUE : 0);
|
|
|
|
if (bold)
|
|
|
|
colors |= BACKGROUND_INTENSITY;
|
2015-03-01 03:08:27 +08:00
|
|
|
colors |= fg_color(current);
|
2009-06-04 15:09:50 +08:00
|
|
|
} else {
|
|
|
|
colors = ((code&1) ? FOREGROUND_RED : 0) |
|
|
|
|
((code&2) ? FOREGROUND_GREEN : 0 ) |
|
|
|
|
((code&4) ? FOREGROUND_BLUE : 0);
|
|
|
|
if (bold)
|
|
|
|
colors |= FOREGROUND_INTENSITY;
|
2015-03-01 03:08:27 +08:00
|
|
|
colors |= bg_color(current);
|
2009-06-04 15:09:50 +08:00
|
|
|
}
|
|
|
|
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), colors);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-04-16 16:56:50 +08:00
|
|
|
static WORD GetConsoleTextAttribute(HANDLE hConsoleOutput) {
|
|
|
|
CONSOLE_SCREEN_BUFFER_INFO info;
|
|
|
|
GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);
|
|
|
|
return info.wAttributes;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *Process::OutputReverse() {
|
2013-09-11 08:36:48 +08:00
|
|
|
if (UseANSI) return "\033[7m";
|
|
|
|
|
2012-04-16 16:56:50 +08:00
|
|
|
const WORD attributes
|
|
|
|
= GetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE));
|
|
|
|
|
|
|
|
const WORD foreground_mask = FOREGROUND_BLUE | FOREGROUND_GREEN |
|
|
|
|
FOREGROUND_RED | FOREGROUND_INTENSITY;
|
|
|
|
const WORD background_mask = BACKGROUND_BLUE | BACKGROUND_GREEN |
|
|
|
|
BACKGROUND_RED | BACKGROUND_INTENSITY;
|
|
|
|
const WORD color_mask = foreground_mask | background_mask;
|
|
|
|
|
|
|
|
WORD new_attributes =
|
|
|
|
((attributes & FOREGROUND_BLUE )?BACKGROUND_BLUE :0) |
|
|
|
|
((attributes & FOREGROUND_GREEN )?BACKGROUND_GREEN :0) |
|
|
|
|
((attributes & FOREGROUND_RED )?BACKGROUND_RED :0) |
|
|
|
|
((attributes & FOREGROUND_INTENSITY)?BACKGROUND_INTENSITY:0) |
|
|
|
|
((attributes & BACKGROUND_BLUE )?FOREGROUND_BLUE :0) |
|
|
|
|
((attributes & BACKGROUND_GREEN )?FOREGROUND_GREEN :0) |
|
|
|
|
((attributes & BACKGROUND_RED )?FOREGROUND_RED :0) |
|
|
|
|
((attributes & BACKGROUND_INTENSITY)?FOREGROUND_INTENSITY:0) |
|
|
|
|
0;
|
|
|
|
new_attributes = (attributes & ~color_mask) | (new_attributes & color_mask);
|
|
|
|
|
|
|
|
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), new_attributes);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-04 15:09:50 +08:00
|
|
|
const char *Process::ResetColor() {
|
2013-09-11 08:36:48 +08:00
|
|
|
if (UseANSI) return "\033[0m";
|
2009-06-04 15:09:50 +08:00
|
|
|
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), defaultColors());
|
|
|
|
return 0;
|
|
|
|
}
|
2014-02-04 22:49:21 +08:00
|
|
|
|
[Support,Windows] Tolerate failure of CryptGenRandom
Summary:
In `Unix/Process.inc`, we seed a random number generator from
`/dev/urandom` if possible, but if not, we're happy to fall back to
ordinary pseudorandom strategies, like the current time and PID.
The corresponding function on Windows calls `CryptGenRandom`, but it
//doesn't// have a fallback if that strategy fails. But `CryptGenRandom`
//can// fail, if a cryptography provider isn't properly initialized, or
occasionally (by our observation) simply intermittently.
If it's reasonable on Unix to implement traditional pseudorandom-number
seeding as a fallback, then it's surely reasonable to do the same on
Windows. So this patch adds a last-ditch use of ordinary rand(), using
much the same strategy as the Unix fallback code.
Reviewers: hans, sammccall
Reviewed By: hans
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77553
2020-04-07 16:18:09 +08:00
|
|
|
static unsigned GetRandomNumberSeed() {
|
|
|
|
// Generate a random number seed from the millisecond-resolution Windows
|
|
|
|
// system clock and the current process id.
|
|
|
|
FILETIME Time;
|
|
|
|
GetSystemTimeAsFileTime(&Time);
|
|
|
|
DWORD Pid = GetCurrentProcessId();
|
|
|
|
return hash_combine(Time.dwHighDateTime, Time.dwLowDateTime, Pid);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned GetPseudoRandomNumber() {
|
|
|
|
// Arrange to call srand once when this function is first used, and
|
|
|
|
// otherwise (if GetRandomNumber always succeeds in using
|
|
|
|
// CryptGenRandom) don't bother at all.
|
|
|
|
static int x = (static_cast<void>(::srand(GetRandomNumberSeed())), 0);
|
|
|
|
(void)x;
|
|
|
|
return ::rand();
|
|
|
|
}
|
|
|
|
|
2014-02-04 22:49:21 +08:00
|
|
|
unsigned Process::GetRandomNumber() {
|
[Support,Windows] Tolerate failure of CryptGenRandom
Summary:
In `Unix/Process.inc`, we seed a random number generator from
`/dev/urandom` if possible, but if not, we're happy to fall back to
ordinary pseudorandom strategies, like the current time and PID.
The corresponding function on Windows calls `CryptGenRandom`, but it
//doesn't// have a fallback if that strategy fails. But `CryptGenRandom`
//can// fail, if a cryptography provider isn't properly initialized, or
occasionally (by our observation) simply intermittently.
If it's reasonable on Unix to implement traditional pseudorandom-number
seeding as a fallback, then it's surely reasonable to do the same on
Windows. So this patch adds a last-ditch use of ordinary rand(), using
much the same strategy as the Unix fallback code.
Reviewers: hans, sammccall
Reviewed By: hans
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77553
2020-04-07 16:18:09 +08:00
|
|
|
// Try to use CryptGenRandom.
|
2014-02-11 10:47:33 +08:00
|
|
|
HCRYPTPROV HCPC;
|
[Support,Windows] Tolerate failure of CryptGenRandom
Summary:
In `Unix/Process.inc`, we seed a random number generator from
`/dev/urandom` if possible, but if not, we're happy to fall back to
ordinary pseudorandom strategies, like the current time and PID.
The corresponding function on Windows calls `CryptGenRandom`, but it
//doesn't// have a fallback if that strategy fails. But `CryptGenRandom`
//can// fail, if a cryptography provider isn't properly initialized, or
occasionally (by our observation) simply intermittently.
If it's reasonable on Unix to implement traditional pseudorandom-number
seeding as a fallback, then it's surely reasonable to do the same on
Windows. So this patch adds a last-ditch use of ordinary rand(), using
much the same strategy as the Unix fallback code.
Reviewers: hans, sammccall
Reviewed By: hans
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77553
2020-04-07 16:18:09 +08:00
|
|
|
if (::CryptAcquireContextW(&HCPC, NULL, NULL, PROV_RSA_FULL,
|
|
|
|
CRYPT_VERIFYCONTEXT)) {
|
|
|
|
ScopedCryptContext CryptoProvider(HCPC);
|
|
|
|
unsigned Ret;
|
|
|
|
if (::CryptGenRandom(CryptoProvider, sizeof(Ret),
|
|
|
|
reinterpret_cast<BYTE *>(&Ret)))
|
|
|
|
return Ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If that fails, fall back to pseudo-random numbers.
|
|
|
|
return GetPseudoRandomNumber();
|
2014-02-04 22:49:21 +08:00
|
|
|
}
|
2018-11-07 07:39:59 +08:00
|
|
|
|
|
|
|
typedef NTSTATUS(WINAPI* RtlGetVersionPtr)(PRTL_OSVERSIONINFOW);
|
|
|
|
#define STATUS_SUCCESS ((NTSTATUS)0x00000000L)
|
|
|
|
|
|
|
|
llvm::VersionTuple llvm::GetWindowsOSVersion() {
|
|
|
|
HMODULE hMod = ::GetModuleHandleW(L"ntdll.dll");
|
|
|
|
if (hMod) {
|
|
|
|
auto getVer = (RtlGetVersionPtr)::GetProcAddress(hMod, "RtlGetVersion");
|
|
|
|
if (getVer) {
|
|
|
|
RTL_OSVERSIONINFOEXW info{};
|
|
|
|
info.dwOSVersionInfoSize = sizeof(info);
|
|
|
|
if (getVer((PRTL_OSVERSIONINFOW)&info) == STATUS_SUCCESS) {
|
|
|
|
return llvm::VersionTuple(info.dwMajorVersion, info.dwMinorVersion, 0,
|
|
|
|
info.dwBuildNumber);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return llvm::VersionTuple(0, 0, 0, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool llvm::RunningWindows8OrGreater() {
|
|
|
|
// Windows 8 is version 6.2, service pack 0.
|
|
|
|
return GetWindowsOSVersion() >= llvm::VersionTuple(6, 2, 0, 0);
|
|
|
|
}
|