llvm-project
157 строк · 5.7 Кб
1//===- Filesystem.cpp -----------------------------------------------------===//
2//
3// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
4// See https://llvm.org/LICENSE.txt for license information.
5// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
6//
7//===----------------------------------------------------------------------===//
8//
9// This file contains a few utility functions to handle files.
10//
11//===----------------------------------------------------------------------===//
12
13#include "lld/Common/Filesystem.h"
14#include "lld/Common/ErrorHandler.h"
15#include "llvm/Config/llvm-config.h"
16#include "llvm/Support/FileOutputBuffer.h"
17#include "llvm/Support/FileSystem.h"
18#include "llvm/Support/Parallel.h"
19#include "llvm/Support/Path.h"
20#include "llvm/Support/TimeProfiler.h"
21#if LLVM_ON_UNIX
22#include <unistd.h>
23#endif
24#include <thread>
25
26using namespace llvm;
27using namespace lld;
28
29// Removes a given file asynchronously. This is a performance hack,
30// so remove this when operating systems are improved.
31//
32// On Linux (and probably on other Unix-like systems), unlink(2) is a
33// noticeably slow system call. As of 2016, unlink takes 250
34// milliseconds to remove a 1 GB file on ext4 filesystem on my machine.
35//
36// To create a new result file, we first remove existing file. So, if
37// you repeatedly link a 1 GB program in a regular compile-link-debug
38// cycle, every cycle wastes 250 milliseconds only to remove a file.
39// Since LLD can link a 1 GB binary in about 5 seconds, that waste
40// actually counts.
41//
42// This function spawns a background thread to remove the file.
43// The calling thread returns almost immediately.
44void lld::unlinkAsync(StringRef path) {
45if (!sys::fs::exists(path) || !sys::fs::is_regular_file(path))
46return;
47
48// Removing a file is async on windows.
49#if defined(_WIN32)
50// On Windows co-operative programs can be expected to open LLD's
51// output in FILE_SHARE_DELETE mode. This allows us to delete the
52// file (by moving it to a temporary filename and then deleting
53// it) so that we can link another output file that overwrites
54// the existing file, even if the current file is in use.
55//
56// This is done on a best effort basis - we do not error if the
57// operation fails. The consequence is merely that the user
58// experiences an inconvenient work-flow.
59//
60// The code here allows LLD to work on all versions of Windows.
61// However, at Windows 10 1903 it seems that the behavior of
62// Windows has changed, so that we could simply delete the output
63// file. This code should be simplified once support for older
64// versions of Windows is dropped.
65//
66// Warning: It seems that the WINVER and _WIN32_WINNT preprocessor
67// defines affect the behavior of the Windows versions of the calls
68// we are using here. If this code stops working this is worth
69// bearing in mind.
70SmallString<128> tmpName;
71if (!sys::fs::createUniqueFile(path + "%%%%%%%%.tmp", tmpName)) {
72if (!sys::fs::rename(path, tmpName))
73path = tmpName;
74else
75sys::fs::remove(tmpName);
76}
77sys::fs::remove(path);
78#else
79if (parallel::strategy.ThreadsRequested == 1)
80return;
81
82// We cannot just remove path from a different thread because we are now going
83// to create path as a new file.
84// Instead we open the file and unlink it on this thread. The unlink is fast
85// since the open fd guarantees that it is not removing the last reference.
86int fd;
87std::error_code ec = sys::fs::openFileForRead(path, fd);
88sys::fs::remove(path);
89
90if (ec)
91return;
92
93// close and therefore remove TempPath in background.
94std::mutex m;
95std::condition_variable cv;
96bool started = false;
97std::thread([&, fd] {
98{
99std::lock_guard<std::mutex> l(m);
100started = true;
101cv.notify_all();
102}
103::close(fd);
104}).detach();
105
106// GLIBC 2.26 and earlier have race condition that crashes an entire process
107// if the main thread calls exit(2) while other thread is starting up.
108std::unique_lock<std::mutex> l(m);
109cv.wait(l, [&] { return started; });
110#endif
111}
112
113// Simulate file creation to see if Path is writable.
114//
115// Determining whether a file is writable or not is amazingly hard,
116// and after all the only reliable way of doing that is to actually
117// create a file. But we don't want to do that in this function
118// because LLD shouldn't update any file if it will end in a failure.
119// We also don't want to reimplement heuristics to determine if a
120// file is writable. So we'll let FileOutputBuffer do the work.
121//
122// FileOutputBuffer doesn't touch a destination file until commit()
123// is called. We use that class without calling commit() to predict
124// if the given file is writable.
125std::error_code lld::tryCreateFile(StringRef path) {
126llvm::TimeTraceScope timeScope("Try create output file");
127if (path.empty())
128return std::error_code();
129if (path == "-")
130return std::error_code();
131return errorToErrorCode(FileOutputBuffer::create(path, 1).takeError());
132}
133
134// Creates an empty file to and returns a raw_fd_ostream to write to it.
135std::unique_ptr<raw_fd_ostream> lld::openFile(StringRef file) {
136std::error_code ec;
137auto ret =
138std::make_unique<raw_fd_ostream>(file, ec, sys::fs::OpenFlags::OF_None);
139if (ec) {
140error("cannot open " + file + ": " + ec.message());
141return nullptr;
142}
143return ret;
144}
145
146// The merged bitcode after LTO is large. Try opening a file stream that
147// supports reading, seeking and writing. Such a file allows BitcodeWriter to
148// flush buffered data to reduce memory consumption. If this fails, open a file
149// stream that supports only write.
150std::unique_ptr<raw_fd_ostream> lld::openLTOOutputFile(StringRef file) {
151std::error_code ec;
152std::unique_ptr<raw_fd_ostream> fs =
153std::make_unique<raw_fd_stream>(file, ec);
154if (!ec)
155return fs;
156return openFile(file);
157}
158