summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows
Commit message (Collapse)AuthorAgeFilesLines
* llvm-ar: Fix MinGW compilationHans Wennborg2020-02-2810-252/+9
| | | | | | | | | | | | | | | | llvm-ar is using CompareStringOrdinal which is available only starting with Windows Vista (WINVER 0x600). Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar. Patch by Cristian Adam! Differential revision: https://reviews.llvm.org/D74599 (cherry picked from commit 01f9abbb50b11dd26b9ccb7cb565cc955d2b9c74) This is for https://bugs.llvm.org/show_bug.cgi?id=44907
* [Support] Don't modify the current EH context during stack unwindingReid Kleckner2020-02-111-1/+7
| | | | | | | | | | | | | Copy it instead. Otherwise, key registers (such as RBP) may get zeroed out by the stack unwinder. Fixes CrashRecoveryTest.DumpStackCleanup with MSVC in release builds. Reviewed By: stella.stamenova Differential Revision: https://reviews.llvm.org/D73809 (cherry picked from commit b074acb82f7e75a189fa7933b09627241b166121)
* [Support] Optionally call signal handlers when a function wrapped by the the ↵Alexandre Ganea2020-01-111-40/+17
| | | | | | | | | CrashRecoveryContext fails This patch allows for handling a failure inside a CrashRecoveryContext in the same way as the global exception/signal handler. A failure will have the same side-effect, such as cleanup of temporarty file, printing callstack, calling relevant signal handlers, and finally returning an exception code. This is an optional feature, disabled by default. This is a support patch for D69825. Differential Revision: https://reviews.llvm.org/D70568
* [Support][NFC] Make some helper functions "static" in Memory.incBruno Ricci2020-01-091-6/+2
|
* Fix issues reported by -Wrange-loop-analysis when building with latest Clang ↵Alexandre Ganea2020-01-071-1/+1
| | | | | | (trunk). NFC. Fixes warning: loop variable 'E' of type 'const llvm::StringRef' creates a copy from type 'const llvm::StringRef' [-Wrange-loop-analysis]
* [Signal] Allow llvm clients to opt into one-shot SIGPIPE handlingVedant Kumar2019-11-181-0/+7
| | | | | | | | | | | | | | | | | | | | Allow clients of the llvm library to opt-in to one-shot SIGPIPE handling, instead of forcing them to undo llvm's SIGPIPE handler registration (which is brittle). The current behavior is preserved for all llvm-derived tools (except lldb) by means of a default-`true` flag in the InitLLVM constructor. This prevents "IO error" crashes in long-lived processes (lldb is the motivating example) which both a) load llvm as a dynamic library and b) *really* need to ignore SIGPIPE. As llvm signal handlers can be installed when calling into libclang (say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the current model. Differential Revision: https://reviews.llvm.org/D70277
* [Support] fix mingw-w64 buildIlya Biryukov2019-11-061-1/+1
| | | | | | | | | | | Older versions of Mingw-w64 do not define _beginthreadex_proc_type, so we replace it with `unsigned (__stdcall *ThreadFunc)(void *)`. Fixes https://github.com/clangd/clangd/issues/188 Patch by lh123! Differential Revision: https://reviews.llvm.org/D69879
* Revert "Disable exit-on-SIGPIPE in lldb"Vedant Kumar2019-10-241-3/+0
| | | | | | | This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30. In post-commit review, Pavel pointed out that there's a simpler way to ignore SIGPIPE in lldb that doesn't rely on llvm's handlers.
* Reland "[Support] Add a way to run a function on a detached thread""Sam McCall2019-10-233-32/+33
| | | | | This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237. The immediate callers have been fixed to pass nullopt where appropriate.
* Revert "[Support] Add a way to run a function on a detached thread"Sam McCall2019-10-233-33/+32
| | | | | | This reverts commit 40668abca4d307e02b33345cfdb7271549ff48d0. This causes clang tests to fail, as stacksize=0 is being explicitly passed and is no longer a no-op.
* [Support] Add a way to run a function on a detached threadSam McCall2019-10-233-32/+33
| | | | | | | | | | | | | | | | | | | | | | | This roughly mimics `std::thread(...).detach()` except it allows to customize the stack size. Required for https://reviews.llvm.org/D50993. I've decided against reusing the existing `llvm_execute_on_thread` because it's not obvious what to do with the ownership of the passed function/arguments: 1. If we pass possibly owning functions data to `llvm_execute_on_thread`, we'll lose the ability to pass small non-owning non-allocating functions for the joining case (as it's used now). Is it important enough? 2. If we use the non-owning interface in the new use case, we'll force clients to transfer ownership to the spawned thread manually, but similar code would still have to exist inside `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same non-owning pointer to pthreads and Windows implementations, and would be forced to wrap it in some structure, and deal with its ownership. Patch by Dmitry Kozhevnikov! Differential Revision: https://reviews.llvm.org/D51103
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-191-0/+1
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* Disable exit-on-SIGPIPE in lldbVedant Kumar2019-10-181-0/+3
| | | | | | | | | | | | | | | | | | Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
* Win: handle \\?\UNC\ prefix in realPathFromHandle (PR43204)Hans Wennborg2019-09-051-6/+12
| | | | | | | | | | | | | | | | | | | | After r361885, realPathFromHandle() ends up getting called on the working directory on each Clang invocation. This unveiled that the code didn't work for paths on network shares. For example, if one maps the local dir c:\src\tmp to x: net use x: \\localhost\c$\tmp and run e.g. "clang -c foo.cc" in x:\, realPathFromHandle will get \\?\UNC\localhost\c$\src\tmp\ back from GetFinalPathNameByHandleW, and would strip off the initial \\?\ prefix, ending up with a path that doesn't work. This patch makes the prefix stripping a little smarter to handle this case. Differential revision: https://reviews.llvm.org/D67166 llvm-svn: 371035
* [Support] Improve readNativeFile(Slice) interfacePavel Labath2019-08-221-49/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was a subtle, but pretty important difference between the Slice and regular versions of this function. The Slice function was zero-initializing the rest of the buffer when the read syscall returned less bytes than expected, while the regular function did not. This patch removes the inconsistency by making both functions *not* zero-initialize the buffer. The zeroing code is moved to the MemoryBuffer class, which is currently the only user of this code. This makes the API more consistent, and the code shorter. While in there, I also refactor the functions to return the number of bytes through the regular return value (via Expected<size_t>) instead of a separate by-ref argument. Reviewers: aganea, rnk Subscribers: kristina, Bigcheese, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66471 llvm-svn: 369627
* Filesystem/Windows: fix inconsistency in readNativeFileSlice APIPavel Labath2019-08-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The windows version implementation of readNativeFileSlice, was trying to match the POSIX behavior of not treating EOF as an error, but it was only handling the case of reading from a pipe. Attempting to read past the end of a regular file returns a slightly different error code, which needs to be handled too. This patch adds ERROR_HANDLE_EOF to the list of error codes to be treated as an end of file, and adds some unit tests for the API. This issue was found while attempting to land D66224, which caused a bunch of lldb tests to start failing on windows. Reviewers: rnk, aganea Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66344 llvm-svn: 369269
* [Support] Base RWMutex on std::shared_timed_mutex (C++14)Benjamin Kramer2019-08-151-128/+0
| | | | | | | | This should have the same semantics. We use std::shared_mutex instead on MSVC and C++17, std::shared_timed_mutex is less efficient than our custom implementation on Windows, std::shared_mutex should be faster. llvm-svn: 369018
* [Support] Base SmartMutex on std::recursive_mutexBenjamin Kramer2019-08-071-56/+0
| | | | | | | | | | | - Remove support for non-recursive mutexes. This was unused. - The std::recursive_mutex is now created/destroyed unconditionally. Locking is still only done if threading is enabled. - Alias SmartScopedLock to std::lock_guard. This should make no semantic difference on the existing APIs. llvm-svn: 368158
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Remove support for unsupported MSVC versionsJF Bastien2019-08-021-6/+0
| | | | | | | | | | | | | | Re-land r367727 with the #if fixed. Reviewers: rnk, lebedev.ri Subscribers: hiraditya, jkorous, dexonsmith, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65662 llvm-svn: 367734
* Revert "Remove support for unsupported MSVC versions"JF Bastien2019-08-021-0/+6
| | | | | | Mismatched preprocessor, I'll fix in a follow-up. llvm-svn: 367728
* Remove support for unsupported MSVC versionsJF Bastien2019-08-021-6/+0
| | | | | | | | | | | | Reviewers: rnk, lebedev.ri Subscribers: hiraditya, jkorous, dexonsmith, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65662 llvm-svn: 367727
* Support for dumping current PrettyStackTrace on SIGINFO (Ctrl-T)Jordan Rose2019-07-121-0/+4
| | | | | | | | | | | | | | | | | | | | Support SIGINFO (and SIGUSR1 for POSIX purposes) to tell what long-running jobs are doing, as inspired by BSD tools (including on macOS), by dumping the current PrettyStackTrace. This adds a new kind of signal handler for non-fatal "info" signals, similar to the "interrupt" handler that already exists for SIGINT (Ctrl-C). It then uses that handler to update a "generation count" managed by the PrettyStackTrace infrastructure, which is then checked whenever a PrettyStackTraceEntry is pushed or popped on each thread. If the generation has changed---i.e. if the user has pressed Ctrl-T---the stack trace is dumped, though unfortunately it can't include the deepest entry because that one is currently being constructed/destructed. https://reviews.llvm.org/D63750 llvm-svn: 365911
* [llvm-objcopy] Don't change permissions of non-regular output filesFangrui Song2019-07-111-2/+6
| | | | | | | | | | | | | | | | | | | | | | There is currently an EPERM error when a regular user executes `llvm-objcopy a.o /dev/null`. Worse, root can even change the mode bits of /dev/null. Fix it by checking if the output file is special. A new overload of llvm::sys::fs::setPermissions with FD as the parameter is added. Users should provide `perm & ~umask` as the parameter if they intend to respect umask. The existing overload of llvm::sys::fs::setPermissions may be deleted if we can find an implementation of fchmod() on Windows. fchmod() is usually better than chmod() because it saves syscalls and can avoid race condition. Reviewed By: jakehehrlich, jhenderson Differential Revision: https://reviews.llvm.org/D64236 llvm-svn: 365753
* [Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner2019-07-101-7/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
* [Support] Add fs::getUmask() function and change fs::setPermissionsAlex Brachet2019-06-281-1/+6
| | | | | | | | | | | | | | | | Summary: This patch changes fs::setPermissions to optionally set permissions while respecting the umask. It also adds the function fs::getUmask() which returns the current umask. Reviewers: jhenderson, rupprecht, aprantl, lhames Reviewed By: jhenderson, rupprecht Subscribers: sanaanajjar231288, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63583 llvm-svn: 364621
* [Support] Renamed member 'Size' to 'AllocatedSize' in MemoryBlock and ↵Lang Hames2019-05-201-7/+7
| | | | | | | | | | | | | | | OwningMemoryBlock. Rename member 'Size' to 'AllocatedSize' in order to provide a hint that the allocated size may be different than the requested size. Comments are added to clarify this point. Updated the InMemoryBuffer in FileOutputBuffer.cpp to track the requested buffer size. Patch by Machiel van Hooren. Thanks Machiel! https://reviews.llvm.org/D61599 llvm-svn: 361195
* [Support] Add error handling to sys::Process::getPageSize().Lang Hames2019-05-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the return type of sys::Process::getPageSize to Expected<unsigned> to account for the fact that the underlying syscalls used to obtain the page size may fail (see below). For clients who use the page size as an optimization only this patch adds a new method, getPageSizeEstimate, which calls through to getPageSize but discards any error returned and substitues a "reasonable" page size estimate estimate instead. All existing LLVM clients are updated to call getPageSizeEstimate rather than getPageSize. On Unix, sys::Process::getPageSize is implemented in terms of getpagesize or sysconf, depending on which macros are set. The sysconf call is documented to return -1 on failure. On Darwin getpagesize is implemented in terms of sysconf and may also fail (though the manpage documentation does not mention this). These failures have been observed in practice when highly restrictive sandbox permissions have been applied. Without this patch, the result is that getPageSize returns -1, which wreaks havoc on any subsequent code that was assuming a sane page size value. <rdar://problem/41654857> Reviewers: dblaikie, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59107 llvm-svn: 360221
* [llvm][Support] Provide interface to set thread prioritiesKadir Cetinkaya2019-04-161-0/+16
| | | | | | | | | | | | | | | | | | | Summary: We have a multi-platform thread priority setting function(last piece landed with D58683), I wanted to make this available to all llvm community, there seem to be other users of such functionality with portability fixmes: lib/Support/CrashRecoveryContext.cpp tools/clang/tools/libclang/CIndex.cpp Reviewers: gribozavr, ioeric Subscribers: krytarowski, jfb, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59130 llvm-svn: 358494
* [Support] MemoryBlock size should reflect the requested sizeAndrew Ng2019-03-271-3/+4
| | | | | | | | | | This patch mirrors the change made to the Unix equivalent in r351916. This in turn fixes bugs related to the use of FileOutputBuffer to output to "-", i.e. stdout, on Windows. Differential Revision: https://reviews.llvm.org/D59663 llvm-svn: 357058
* Fix SupportTests.exe/AllocationTests/MappedMemoryTest.AllocAndReleaseHuge ↵Alexandre Ganea2019-02-281-3/+3
| | | | | | when the machine doesn't have large pages enabled. llvm-svn: 355067
* [Memory] Add basic support for large/huge memory pagesAlexandre Ganea2019-02-281-18/+54
| | | | | | | | | | | | | | | | | This patch introduces Memory::MF_HUGE_HINT which indicates that allocateMappedMemory() shall return a pointer to a large memory page. However the flag is a hint because we're not guaranteed in any way that we will get back a large memory page. There are several restrictions: - Large/huge memory pages aren't enabled by default on modern OSes (Windows 10 and Linux at least), and should be manually enabled/reserved. - Once enabled, it should be kept in mind that large pages are physical only, they can't be swapped. - Memory fragmentation can affect the availability of large pages, especially after running the OS for a long time and/or running along many other applications. Memory::allocateMappedMemory() will fallback to 4KB pages if it can't allocate 2MB large pages (if Memory::MF_HUGE_HINT is provided) Currently, Memory::MF_HUGE_HINT only works on Windows. The hint will be ignored on Linux, 4KB pages will always be returned. Differential Revision: https://reviews.llvm.org/D58718 llvm-svn: 355065
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1914-56/+42
| | | | | | | | | | | | | | | | | 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
* Don't write #include "Windows/WindowsSupport.h" from the Windows dir.Zachary Turner2019-01-081-1/+1
| | | | | | | This generates -Wnonportable-include-dir warnings, and doesn't need to be there. It seems this was just checked in on accident. llvm-svn: 350655
* [Support] Fix FileNameLength passed to SetFileInformationByHandleShoaib Meenai2018-12-131-1/+1
| | | | | | | | | | | | | | | | The rename_internal function used for Windows has a minor bug where the filename length is passed as a character count instead of a byte count. Windows internally ignores this field, but other tools that hook NT api's may use the documented behavior: MSDN documentation specifying the size should be in bytes: https://docs.microsoft.com/en-us/windows/desktop/api/winbase/ns-winbase-_file_rename_info Patch by Ben Hillis. Differential Revision: https://reviews.llvm.org/D55624 llvm-svn: 348995
* [FileSystem] Add expand_tilde functionJonas Devlieghere2018-11-131-0/+11
| | | | | | | | | | | | In D54435 there was some discussion about the expand_tilde flag for real_path that I wanted to expose through the VFS. The consensus is that these two things should be separate functions. Since we already have the code for this I went ahead and added a function expand_tilde that does just that. Differential revision: https://reviews.llvm.org/D54448 llvm-svn: 346776
* [Windows] Simplify WindowsSupport.hReid Kleckner2018-11-063-82/+54
| | | | | | | | | | | | | | | | | 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
* Silence deprecation warning for GetVersionEx with clang-clReid Kleckner2018-11-061-0/+7
| | | | llvm-svn: 346268
* [Support] Fix `warning: unknown pragma ignored` for mingw targetMartin Storsjo2018-11-061-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D54133 llvm-svn: 346218
* Only call FlushFileBuffers() when writing executables on WindowsAlexandre Ganea2018-11-052-1/+57
| | | | | | | | | | | | This is a follow-up for "r325274: Call FlushFileBuffers on output files." Previously, FlushFileBuffers() was called in all cases when writing a file. The objective was to go around a bug in the Windows kernel (as described here: https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/). However that is required only when writing EXEs, any other file type doesn't need flushing. This patch calls FlushFileBuffers() only for EXEs. In addition, we completly disable FlushFileBuffers() for known Windows 10 versions that do not exhibit the original kernel bug. Differential Revision: https://reviews.llvm.org/D53727 llvm-svn: 346152
* Remove dead function user_cache_directory()Nico Weber2018-09-181-4/+0
| | | | | | | | | | | | It's been unused since it was added almost 3 years ago in https://reviews.llvm.org/D13801 Motivated by https://reviews.llvm.org/rL342002 since it removes one of the functions keeping a ref to SHGetKnownFolderPath. Differential Revision: https://reviews.llvm.org/D52184 llvm-svn: 342485
* [Support] sys::fs::directory_entry includes the file_type.Kristina Brooks2018-09-121-38/+42
| | | | | | | | | | | | | | | | This is available on most platforms (Linux/Mac/Win/BSD) with no extra syscalls. On other platforms (e.g. Solaris) we stat() if this information is requested. This will allow switching clang's VFS to efficiently expose (path, type) when traversing a directory. Currently it exposes an entire Status, but does so by calling fs::status() on all platforms. Almost all callers only need the path, and all callers only need (path, type). Patch by sammccall (Sam McCall) Differential Revision: https://reviews.llvm.org/D51918 llvm-svn: 342089
* [Support] Quote arguments containing \n on WindowsReid Kleckner2018-09-111-1/+1
| | | | | | | | | Fixes at_file.c test failure caused by r341988. We may want to change how we treat \n in our tokenizer, but this is probably a good fix regardless, since we can invoke all kinds of programs with different interpretations of the command line quoting rules. llvm-svn: 341992
* [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
* [Support] NFC: Allow modifying access/modification times independently in ↵Jordan Rupprecht2018-08-131-3/+5
| | | | | | | | | | | | | | | | | sys::fs::setLastModificationAndAccessTime. Summary: Add an overload to sys::fs::setLastModificationAndAccessTime that allows setting last access and modification times separately. This will allow tools to use this API when they want to preserve both the access and modification times from an input file, which may be different. Also note that both the POSIX (futimens/futimes) and Windows (SetFileTime) APIs take the two timestamps in the order of (1) access (2) modification time, so this renames the method to "setLastAccessAndModificationTime" to make it clear which timestamp is which. For existing callers, the 1-arg overload just sets both timestamps to the same thing. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50521 llvm-svn: 339628
* [Windows FS] Allow moving files in TempFile::keepJeremy Morse2018-08-031-1/+1
| | | | | | | | | | | | In r338216 / D49860 TempFile::keep was extended to allow keeping across filesystems. The aim on Windows was to have this happen in rename_internal using the existing system API. However, to fix an issue and preserve the idea of "renaming" not being a move, put Windows keep-across-filesystem in TempFile::keep. Differential Revision: https://reviews.llvm.org/D50048 llvm-svn: 338841
* [dsymutil] Simplify temporary file handling.Jonas Devlieghere2018-07-291-1/+1
| | | | | | | | | | | Dsymutil's update functionality was broken on Windows because we tried to rename a file while we're holding open handles to that file. TempFile provides a solution for this through its keep(Twine) method. This patch changes dsymutil to make use of that functionality. Differential revision: https://reviews.llvm.org/D49860 llvm-svn: 338216
* [ThinLTO] Update ThinLTO cache file atimes when on WindowsAndrew Ng2018-07-041-0/+15
| | | | | | | | | | | | | | | | | | ThinLTO cache file access times are used for expiration based pruning and since Vista, file access times are not updated by Windows by default: https://blogs.technet.microsoft.com/filecab/2006/11/07/disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance This means on Windows, cache files are currently being pruned from creation time. This change manually updates cache files that are accessed by ThinLTO, when on Windows. Patch by Owen Reynolds. Differential Revision: https://reviews.llvm.org/D47266 llvm-svn: 336276
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-131-71/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows we've observed that if you open a file, write to it, map it into memory and close the file handle, the contents of the memory mapping can sometimes be incorrect. That was what we did when adding an entry to the ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing intermittent build failures on Chromium's ThinLTO bots on Windows. More details are in the associated Chromium bug (crbug.com/786127). We can prevent this from happening by keeping a handle to the file open while the mapping is active. So this patch changes the mapped_file_region class to duplicate the file handle when mapping the file and close it upon unmapping it. One gotcha is that the file handle that we keep open must not have been created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system will prevent other processes from opening the file. We can achieve this by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead, we use SetFileInformationByHandle with FileDispositionInfo to manage the delete-on-close bit. This lets us remove the hack that we used to use to clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE. A downside of using SetFileInformationByHandle/FileDispositionInfo as opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using CreateFile to open the file while the flag is set, even within the same process. This doesn't seem to matter for almost every client of TempFile, except for LockFileManager, which calls sys::fs::create_link to create a hard link from the lock file, and in the process of doing so tries to open the file. To prevent this change from breaking LockFileManager I changed it to stop using TempFile by effectively reverting r318550. Differential Revision: https://reviews.llvm.org/D48051 llvm-svn: 334630
OpenPOWER on IntegriCloud