LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
llvm-svn: 329696
It is private to llvm. Instead use llvm/Config/llvm-config.h and check
LLVM_ON_UNIX. That is the same guard that clang uses before including
unistd.h.
llvm-svn: 318558
I think the constract of this function is to remove a file in some way,
whether in background or in foreground. This patch makes sure that it
removes a given file.
Differential Revision: https://reviews.llvm.org/D39778
llvm-svn: 317663
It used to rename the file before removing it in a background thread.
A simpler way to delay the removal is simply to open the file.
Since this is a posix specific issue, simplify the windows
implementation.
llvm-svn: 317631
This function is always called with Config->OutputFile. That is not
obvious from reading the function. It should always use Path or take
no argument and always use Config->OutputFile.
llvm-svn: 317536
Summary:
This will allow using the functionality from other linkers. It is also
a prerequisite for sharing the error logging code.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: emaste, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38822
llvm-svn: 315725
I think it is not defined what would happen to detached threads
when the main thread tries to exit. That means it was not guaranteed
that unlinkAsync correctly removes a temporary file. It was also
reported that this unlinkAsync caused a crash on Windows.
This patch adds a few new functions so that the main thread always
waits for non-main threads before exitting.
I don't actually like the new two functions, runBackground and
waitForBackgroundThreads, because it looks like it is a bit
overdesigned. After all, what we are doing with these functions
is to just remove a file.
An alternative would be to do fork(2) and make the child process
remove a file asynchronously. However, it has its own problems.
Correctly forking and reclaiming a resource using waitpid(2) is not
doable unless we know our process-wide settings (such as signal mask),
but we can't make any assumption on it when lld is embedded to other
process. So I chose to stick with threads instead of multi-processes.
Differential Revision: https://reviews.llvm.org/D38571
llvm-svn: 315033
Summary:
If the output file is a character file (e.g. /dev/null) unlinking it could
potentially destabilize the user's system. For example,
unlinking causes `lld %input -o /dev/null` to replace /dev/null with a
regular file, which will lead to unexpected behavior in other programs
that read from /dev/null, and worse than expected peformance for
programs that write to /dev/null.
This makes it possible to run the test-release.sh script as root.
Prior to this patch, the ELF/basic.s test would replace
/dev/null with a regular file, which would cause crashes in llvm
test-suite programs that piped /dev/null to stdin.
For example, if you run the test-relase.sh script as root,
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D34917
llvm-svn: 307092
isFileWritable() checked if a file is writable and then emitted
an error message if it is not writable. So it did more than the
name says. This patch moves error() calls to Driver.
llvm-svn: 301422
As with the changes made in r297645, we do not want a potentially long link to
be run, if it will ultimately fail because the map file is not writable. This
change reuses the same functionality as the output file path check. See
https://reviews.llvm.org/D30449 for further justification and explanations.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D31603
llvm-svn: 299420
Nico Weber