2018-03-21 05:08:59 +08:00
|
|
|
//===- Job.cpp - Command to Execute ---------------------------------------===//
|
2009-03-14 07:36:33 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-07-19 03:02:11 +08:00
|
|
|
#include "clang/Driver/Job.h"
|
2015-07-17 11:35:54 +08:00
|
|
|
#include "InputInfo.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "clang/Basic/LLVM.h"
|
2014-02-19 05:42:51 +08:00
|
|
|
#include "clang/Driver/Driver.h"
|
|
|
|
#include "clang/Driver/DriverDiagnostic.h"
|
|
|
|
#include "clang/Driver/Tool.h"
|
|
|
|
#include "clang/Driver/ToolChain.h"
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2016-07-19 03:02:11 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2013-09-13 02:23:34 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
#include "llvm/ADT/StringSet.h"
|
2013-09-13 02:23:34 +08:00
|
|
|
#include "llvm/ADT/StringSwitch.h"
|
2016-12-09 10:22:47 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2016-07-19 03:02:11 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2013-09-13 02:35:08 +08:00
|
|
|
#include "llvm/Support/Program.h"
|
2013-09-13 02:23:34 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include <algorithm>
|
2009-03-14 07:36:33 +08:00
|
|
|
#include <cassert>
|
2018-03-21 05:08:59 +08:00
|
|
|
#include <cstddef>
|
|
|
|
#include <string>
|
|
|
|
#include <system_error>
|
|
|
|
#include <utility>
|
|
|
|
|
|
|
|
using namespace clang;
|
|
|
|
using namespace driver;
|
2009-03-14 07:36:33 +08:00
|
|
|
|
2015-07-03 06:52:04 +08:00
|
|
|
Command::Command(const Action &Source, const Tool &Creator,
|
2018-10-13 02:55:36 +08:00
|
|
|
const char *Executable,
|
|
|
|
const llvm::opt::ArgStringList &Arguments,
|
2015-07-17 11:35:54 +08:00
|
|
|
ArrayRef<InputInfo> Inputs)
|
2015-07-03 06:52:08 +08:00
|
|
|
: Source(Source), Creator(Creator), Executable(Executable),
|
2018-03-21 05:08:59 +08:00
|
|
|
Arguments(Arguments) {
|
2015-07-17 11:35:54 +08:00
|
|
|
for (const auto &II : Inputs)
|
|
|
|
if (II.isFilename())
|
|
|
|
InputFilenames.push_back(II.getFilename());
|
|
|
|
}
|
2009-03-14 07:36:33 +08:00
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Check if the compiler flag in question should be skipped when
|
2016-12-09 10:22:47 +08:00
|
|
|
/// emitting a reproducer. Also track how many arguments it has and if the
|
|
|
|
/// option is some kind of include path.
|
|
|
|
static bool skipArgs(const char *Flag, bool HaveCrashVFS, int &SkipNum,
|
|
|
|
bool &IsInclude) {
|
|
|
|
SkipNum = 2;
|
2013-09-13 02:23:34 +08:00
|
|
|
// These flags are all of the form -Flag <Arg> and are treated as two
|
|
|
|
// arguments. Therefore, we need to skip the flag and the next argument.
|
2016-12-09 10:22:47 +08:00
|
|
|
bool ShouldSkip = llvm::StringSwitch<bool>(Flag)
|
2016-04-05 04:26:57 +08:00
|
|
|
.Cases("-MF", "-MT", "-MQ", "-serialize-diagnostic-file", true)
|
2017-05-01 21:05:04 +08:00
|
|
|
.Cases("-o", "-dependency-file", true)
|
2016-12-13 03:28:25 +08:00
|
|
|
.Cases("-fdebug-compilation-dir", "-diagnostic-log-file", true)
|
2014-06-23 04:35:10 +08:00
|
|
|
.Cases("-dwarf-debug-flags", "-ivfsoverlay", true)
|
2013-09-13 02:23:34 +08:00
|
|
|
.Default(false);
|
2016-12-09 10:22:47 +08:00
|
|
|
if (ShouldSkip)
|
|
|
|
return true;
|
2013-09-13 02:23:34 +08:00
|
|
|
|
2016-12-09 10:22:47 +08:00
|
|
|
// Some include flags shouldn't be skipped if we have a crash VFS
|
|
|
|
IsInclude = llvm::StringSwitch<bool>(Flag)
|
|
|
|
.Cases("-include", "-header-include-file", true)
|
|
|
|
.Cases("-idirafter", "-internal-isystem", "-iwithprefix", true)
|
|
|
|
.Cases("-internal-externc-isystem", "-iprefix", true)
|
|
|
|
.Cases("-iwithprefixbefore", "-isystem", "-iquote", true)
|
|
|
|
.Cases("-isysroot", "-I", "-F", "-resource-dir", true)
|
2017-12-12 02:14:51 +08:00
|
|
|
.Cases("-iframework", "-include-pch", true)
|
2016-12-09 10:22:47 +08:00
|
|
|
.Default(false);
|
|
|
|
if (IsInclude)
|
2018-03-21 05:08:59 +08:00
|
|
|
return !HaveCrashVFS;
|
2013-09-13 02:23:34 +08:00
|
|
|
|
|
|
|
// The remaining flags are treated as a single argument.
|
|
|
|
|
|
|
|
// These flags are all of the form -Flag and have no second argument.
|
2016-12-09 10:22:47 +08:00
|
|
|
ShouldSkip = llvm::StringSwitch<bool>(Flag)
|
2017-10-20 08:25:07 +08:00
|
|
|
.Cases("-M", "-MM", "-MG", "-MP", "-MD", true)
|
|
|
|
.Case("-MMD", true)
|
2013-09-13 02:23:34 +08:00
|
|
|
.Default(false);
|
|
|
|
|
|
|
|
// Match found.
|
2016-12-09 10:22:47 +08:00
|
|
|
SkipNum = 1;
|
|
|
|
if (ShouldSkip)
|
|
|
|
return true;
|
2013-09-13 02:23:34 +08:00
|
|
|
|
|
|
|
// These flags are treated as a single argument (e.g., -F<Dir>).
|
|
|
|
StringRef FlagRef(Flag);
|
2016-12-09 10:22:47 +08:00
|
|
|
IsInclude = FlagRef.startswith("-F") || FlagRef.startswith("-I");
|
|
|
|
if (IsInclude)
|
2018-03-21 05:08:59 +08:00
|
|
|
return !HaveCrashVFS;
|
2016-12-09 10:22:47 +08:00
|
|
|
if (FlagRef.startswith("-fmodules-cache-path="))
|
|
|
|
return true;
|
2013-09-13 02:23:34 +08:00
|
|
|
|
2016-12-09 10:22:47 +08:00
|
|
|
SkipNum = 0;
|
|
|
|
return false;
|
2013-09-13 02:23:34 +08:00
|
|
|
}
|
|
|
|
|
2016-10-08 09:38:43 +08:00
|
|
|
void Command::printArg(raw_ostream &OS, StringRef Arg, bool Quote) {
|
|
|
|
const bool Escape = Arg.find_first_of("\"\\$") != StringRef::npos;
|
2013-09-13 02:23:34 +08:00
|
|
|
|
|
|
|
if (!Quote && !Escape) {
|
|
|
|
OS << Arg;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Quote and escape. This isn't really complete, but good enough.
|
|
|
|
OS << '"';
|
2018-03-21 05:08:59 +08:00
|
|
|
for (const auto c : Arg) {
|
2013-09-13 02:23:34 +08:00
|
|
|
if (c == '"' || c == '\\' || c == '$')
|
|
|
|
OS << '\\';
|
|
|
|
OS << c;
|
|
|
|
}
|
|
|
|
OS << '"';
|
|
|
|
}
|
|
|
|
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
void Command::writeResponseFile(raw_ostream &OS) const {
|
|
|
|
// In a file list, we only write the set of inputs to the response file
|
|
|
|
if (Creator.getResponseFilesSupport() == Tool::RF_FileList) {
|
2018-03-21 05:08:59 +08:00
|
|
|
for (const auto *Arg : InputFileList) {
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
OS << Arg << '\n';
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-07-16 06:42:37 +08:00
|
|
|
// In regular response files, we send all arguments to the response file.
|
|
|
|
// Wrapping all arguments in double quotes ensures that both Unix tools and
|
|
|
|
// Windows tools understand the response file.
|
2018-03-21 05:08:59 +08:00
|
|
|
for (const auto *Arg : Arguments) {
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
OS << '"';
|
|
|
|
|
|
|
|
for (; *Arg != '\0'; Arg++) {
|
|
|
|
if (*Arg == '\"' || *Arg == '\\') {
|
|
|
|
OS << '\\';
|
|
|
|
}
|
|
|
|
OS << *Arg;
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << "\" ";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Command::buildArgvForResponseFile(
|
|
|
|
llvm::SmallVectorImpl<const char *> &Out) const {
|
|
|
|
// When not a file list, all arguments are sent to the response file.
|
|
|
|
// This leaves us to set the argv to a single parameter, requesting the tool
|
|
|
|
// to read the response file.
|
|
|
|
if (Creator.getResponseFilesSupport() != Tool::RF_FileList) {
|
|
|
|
Out.push_back(Executable);
|
|
|
|
Out.push_back(ResponseFileFlag.c_str());
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::StringSet<> Inputs;
|
2018-03-21 05:08:59 +08:00
|
|
|
for (const auto *InputName : InputFileList)
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
Inputs.insert(InputName);
|
|
|
|
Out.push_back(Executable);
|
|
|
|
// In a file list, build args vector ignoring parameters that will go in the
|
|
|
|
// response file (elements of the InputFileList vector)
|
|
|
|
bool FirstInput = true;
|
2018-03-21 05:08:59 +08:00
|
|
|
for (const auto *Arg : Arguments) {
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
if (Inputs.count(Arg) == 0) {
|
|
|
|
Out.push_back(Arg);
|
|
|
|
} else if (FirstInput) {
|
|
|
|
FirstInput = false;
|
|
|
|
Out.push_back(Creator.getResponseFileFlag());
|
|
|
|
Out.push_back(ResponseFile);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Rewrite relative include-like flag paths to absolute ones.
|
2016-12-09 10:22:47 +08:00
|
|
|
static void
|
|
|
|
rewriteIncludes(const llvm::ArrayRef<const char *> &Args, size_t Idx,
|
|
|
|
size_t NumArgs,
|
|
|
|
llvm::SmallVectorImpl<llvm::SmallString<128>> &IncFlags) {
|
|
|
|
using namespace llvm;
|
|
|
|
using namespace sys;
|
2018-03-21 05:08:59 +08:00
|
|
|
|
2016-12-09 10:22:47 +08:00
|
|
|
auto getAbsPath = [](StringRef InInc, SmallVectorImpl<char> &OutInc) -> bool {
|
|
|
|
if (path::is_absolute(InInc)) // Nothing to do here...
|
|
|
|
return false;
|
|
|
|
std::error_code EC = fs::current_path(OutInc);
|
|
|
|
if (EC)
|
|
|
|
return false;
|
|
|
|
path::append(OutInc, InInc);
|
|
|
|
return true;
|
|
|
|
};
|
|
|
|
|
|
|
|
SmallString<128> NewInc;
|
|
|
|
if (NumArgs == 1) {
|
|
|
|
StringRef FlagRef(Args[Idx + NumArgs - 1]);
|
|
|
|
assert((FlagRef.startswith("-F") || FlagRef.startswith("-I")) &&
|
|
|
|
"Expecting -I or -F");
|
|
|
|
StringRef Inc = FlagRef.slice(2, StringRef::npos);
|
|
|
|
if (getAbsPath(Inc, NewInc)) {
|
|
|
|
SmallString<128> NewArg(FlagRef.slice(0, 2));
|
|
|
|
NewArg += NewInc;
|
|
|
|
IncFlags.push_back(std::move(NewArg));
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(NumArgs == 2 && "Not expecting more than two arguments");
|
|
|
|
StringRef Inc(Args[Idx + NumArgs - 1]);
|
|
|
|
if (!getAbsPath(Inc, NewInc))
|
|
|
|
return;
|
|
|
|
IncFlags.push_back(SmallString<128>(Args[Idx]));
|
|
|
|
IncFlags.push_back(std::move(NewInc));
|
|
|
|
}
|
|
|
|
|
2013-09-13 02:23:34 +08:00
|
|
|
void Command::Print(raw_ostream &OS, const char *Terminator, bool Quote,
|
2014-10-22 01:24:44 +08:00
|
|
|
CrashReportInfo *CrashInfo) const {
|
2014-08-06 04:49:12 +08:00
|
|
|
// Always quote the exe.
|
2014-08-07 08:05:00 +08:00
|
|
|
OS << ' ';
|
2015-07-09 14:58:31 +08:00
|
|
|
printArg(OS, Executable, /*Quote=*/true);
|
2013-09-13 02:23:34 +08:00
|
|
|
|
2018-03-21 05:08:59 +08:00
|
|
|
ArrayRef<const char *> Args = Arguments;
|
|
|
|
SmallVector<const char *, 128> ArgsRespFile;
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
if (ResponseFile != nullptr) {
|
|
|
|
buildArgvForResponseFile(ArgsRespFile);
|
|
|
|
Args = ArrayRef<const char *>(ArgsRespFile).slice(1); // no executable name
|
|
|
|
}
|
|
|
|
|
2015-03-12 08:52:56 +08:00
|
|
|
bool HaveCrashVFS = CrashInfo && !CrashInfo->VFSPath.empty();
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
for (size_t i = 0, e = Args.size(); i < e; ++i) {
|
|
|
|
const char *const Arg = Args[i];
|
2013-09-13 02:23:34 +08:00
|
|
|
|
2014-10-22 01:24:44 +08:00
|
|
|
if (CrashInfo) {
|
2016-12-09 10:22:47 +08:00
|
|
|
int NumArgs = 0;
|
|
|
|
bool IsInclude = false;
|
|
|
|
if (skipArgs(Arg, HaveCrashVFS, NumArgs, IsInclude)) {
|
|
|
|
i += NumArgs - 1;
|
2013-09-13 02:23:34 +08:00
|
|
|
continue;
|
2015-07-17 11:35:54 +08:00
|
|
|
}
|
2016-12-09 10:22:47 +08:00
|
|
|
|
|
|
|
// Relative includes need to be expanded to absolute paths.
|
|
|
|
if (HaveCrashVFS && IsInclude) {
|
|
|
|
SmallVector<SmallString<128>, 2> NewIncFlags;
|
|
|
|
rewriteIncludes(Args, i, NumArgs, NewIncFlags);
|
|
|
|
if (!NewIncFlags.empty()) {
|
|
|
|
for (auto &F : NewIncFlags) {
|
|
|
|
OS << ' ';
|
|
|
|
printArg(OS, F.c_str(), Quote);
|
|
|
|
}
|
|
|
|
i += NumArgs - 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-17 11:35:54 +08:00
|
|
|
auto Found = std::find_if(InputFilenames.begin(), InputFilenames.end(),
|
|
|
|
[&Arg](StringRef IF) { return IF == Arg; });
|
|
|
|
if (Found != InputFilenames.end() &&
|
|
|
|
(i == 0 || StringRef(Args[i - 1]) != "-main-file-name")) {
|
2014-10-22 01:24:44 +08:00
|
|
|
// Replace the input file name with the crashinfo's file name.
|
|
|
|
OS << ' ';
|
|
|
|
StringRef ShortName = llvm::sys::path::filename(CrashInfo->Filename);
|
2016-11-02 18:39:27 +08:00
|
|
|
printArg(OS, ShortName.str(), Quote);
|
2014-10-22 01:24:44 +08:00
|
|
|
continue;
|
2013-09-13 02:23:34 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << ' ';
|
2015-07-09 14:58:31 +08:00
|
|
|
printArg(OS, Arg, Quote);
|
2013-09-13 02:23:34 +08:00
|
|
|
}
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
|
2015-03-12 08:52:56 +08:00
|
|
|
if (CrashInfo && HaveCrashVFS) {
|
2014-10-22 01:24:44 +08:00
|
|
|
OS << ' ';
|
2015-07-09 14:58:31 +08:00
|
|
|
printArg(OS, "-ivfsoverlay", Quote);
|
2014-10-22 01:24:44 +08:00
|
|
|
OS << ' ';
|
2016-11-02 18:39:27 +08:00
|
|
|
printArg(OS, CrashInfo->VFSPath.str(), Quote);
|
2016-04-02 01:39:08 +08:00
|
|
|
|
2016-12-09 11:11:48 +08:00
|
|
|
// The leftover modules from the crash are stored in
|
|
|
|
// <name>.cache/vfs/modules
|
|
|
|
// Leave it untouched for pcm inspection and provide a clean/empty dir
|
|
|
|
// path to contain the future generated module cache:
|
|
|
|
// <name>.cache/vfs/repro-modules
|
2016-04-02 01:39:08 +08:00
|
|
|
SmallString<128> RelModCacheDir = llvm::sys::path::parent_path(
|
|
|
|
llvm::sys::path::parent_path(CrashInfo->VFSPath));
|
2016-12-09 11:11:48 +08:00
|
|
|
llvm::sys::path::append(RelModCacheDir, "repro-modules");
|
2016-04-02 01:39:08 +08:00
|
|
|
|
|
|
|
std::string ModCachePath = "-fmodules-cache-path=";
|
|
|
|
ModCachePath.append(RelModCacheDir.c_str());
|
|
|
|
|
|
|
|
OS << ' ';
|
2016-11-02 18:39:27 +08:00
|
|
|
printArg(OS, ModCachePath, Quote);
|
2014-10-22 01:24:44 +08:00
|
|
|
}
|
|
|
|
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
if (ResponseFile != nullptr) {
|
|
|
|
OS << "\n Arguments passed via response file:\n";
|
|
|
|
writeResponseFile(OS);
|
|
|
|
// Avoiding duplicated newline terminator, since FileLists are
|
|
|
|
// newline-separated.
|
|
|
|
if (Creator.getResponseFilesSupport() != Tool::RF_FileList)
|
|
|
|
OS << "\n";
|
|
|
|
OS << " (end of response file)";
|
|
|
|
}
|
|
|
|
|
2013-09-13 02:23:34 +08:00
|
|
|
OS << Terminator;
|
|
|
|
}
|
|
|
|
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
void Command::setResponseFile(const char *FileName) {
|
|
|
|
ResponseFile = FileName;
|
|
|
|
ResponseFileFlag = Creator.getResponseFileFlag();
|
|
|
|
ResponseFileFlag += FileName;
|
|
|
|
}
|
|
|
|
|
2017-03-18 00:24:34 +08:00
|
|
|
void Command::setEnvironment(llvm::ArrayRef<const char *> NewEnvironment) {
|
|
|
|
Environment.reserve(NewEnvironment.size() + 1);
|
|
|
|
Environment.assign(NewEnvironment.begin(), NewEnvironment.end());
|
|
|
|
Environment.push_back(nullptr);
|
|
|
|
}
|
|
|
|
|
2017-09-14 01:45:51 +08:00
|
|
|
int Command::Execute(ArrayRef<llvm::Optional<StringRef>> Redirects,
|
2017-09-14 01:03:58 +08:00
|
|
|
std::string *ErrMsg, bool *ExecutionFailed) const {
|
2018-10-14 03:13:14 +08:00
|
|
|
if (PrintInputFilenames) {
|
|
|
|
for (const char *Arg : InputFilenames)
|
|
|
|
llvm::outs() << llvm::sys::path::filename(Arg) << "\n";
|
|
|
|
llvm::outs().flush();
|
|
|
|
}
|
|
|
|
|
2013-09-13 02:35:08 +08:00
|
|
|
SmallVector<const char*, 128> Argv;
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
|
2018-06-13 01:43:52 +08:00
|
|
|
Optional<ArrayRef<StringRef>> Env;
|
2018-07-04 02:12:39 +08:00
|
|
|
std::vector<StringRef> ArgvVectorStorage;
|
2018-06-13 01:43:52 +08:00
|
|
|
if (!Environment.empty()) {
|
2017-03-18 00:24:34 +08:00
|
|
|
assert(Environment.back() == nullptr &&
|
|
|
|
"Environment vector should be null-terminated by now");
|
2018-07-04 02:12:39 +08:00
|
|
|
ArgvVectorStorage = llvm::toStringRefArray(Environment.data());
|
|
|
|
Env = makeArrayRef(ArgvVectorStorage);
|
2017-03-18 00:24:34 +08:00
|
|
|
}
|
|
|
|
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
if (ResponseFile == nullptr) {
|
|
|
|
Argv.push_back(Executable);
|
2015-02-18 00:48:30 +08:00
|
|
|
Argv.append(Arguments.begin(), Arguments.end());
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
Argv.push_back(nullptr);
|
|
|
|
|
2018-06-13 01:43:52 +08:00
|
|
|
auto Args = llvm::toStringRefArray(Argv.data());
|
2017-03-18 00:24:34 +08:00
|
|
|
return llvm::sys::ExecuteAndWait(
|
2018-06-13 01:43:52 +08:00
|
|
|
Executable, Args, Env, Redirects, /*secondsToWait*/ 0,
|
2017-03-18 00:24:34 +08:00
|
|
|
/*memoryLimit*/ 0, ErrMsg, ExecutionFailed);
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// We need to put arguments in a response file (command is too large)
|
|
|
|
// Open stream to store the response file contents
|
|
|
|
std::string RespContents;
|
|
|
|
llvm::raw_string_ostream SS(RespContents);
|
|
|
|
|
|
|
|
// Write file contents and build the Argv vector
|
|
|
|
writeResponseFile(SS);
|
|
|
|
buildArgvForResponseFile(Argv);
|
2014-05-18 00:56:41 +08:00
|
|
|
Argv.push_back(nullptr);
|
Teach Clang how to use response files when calling other tools
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
llvm-svn: 217792
2014-09-16 01:45:39 +08:00
|
|
|
SS.flush();
|
|
|
|
|
|
|
|
// Save the response file in the appropriate encoding
|
|
|
|
if (std::error_code EC = writeFileWithEncoding(
|
|
|
|
ResponseFile, RespContents, Creator.getResponseFileEncoding())) {
|
|
|
|
if (ErrMsg)
|
|
|
|
*ErrMsg = EC.message();
|
|
|
|
if (ExecutionFailed)
|
|
|
|
*ExecutionFailed = true;
|
|
|
|
return -1;
|
|
|
|
}
|
2013-09-13 02:35:08 +08:00
|
|
|
|
2018-06-13 01:43:52 +08:00
|
|
|
auto Args = llvm::toStringRefArray(Argv.data());
|
|
|
|
return llvm::sys::ExecuteAndWait(Executable, Args, Env, Redirects,
|
2017-03-18 00:24:34 +08:00
|
|
|
/*secondsToWait*/ 0,
|
2013-09-13 02:35:08 +08:00
|
|
|
/*memoryLimit*/ 0, ErrMsg, ExecutionFailed);
|
|
|
|
}
|
|
|
|
|
2013-09-20 04:32:16 +08:00
|
|
|
FallbackCommand::FallbackCommand(const Action &Source_, const Tool &Creator_,
|
|
|
|
const char *Executable_,
|
2018-10-13 02:55:36 +08:00
|
|
|
const llvm::opt::ArgStringList &Arguments_,
|
2015-07-17 11:35:54 +08:00
|
|
|
ArrayRef<InputInfo> Inputs,
|
2014-09-05 00:04:28 +08:00
|
|
|
std::unique_ptr<Command> Fallback_)
|
2015-07-17 11:35:54 +08:00
|
|
|
: Command(Source_, Creator_, Executable_, Arguments_, Inputs),
|
2014-09-05 00:04:28 +08:00
|
|
|
Fallback(std::move(Fallback_)) {}
|
2013-09-20 04:32:16 +08:00
|
|
|
|
|
|
|
void FallbackCommand::Print(raw_ostream &OS, const char *Terminator,
|
2014-10-22 01:24:44 +08:00
|
|
|
bool Quote, CrashReportInfo *CrashInfo) const {
|
|
|
|
Command::Print(OS, "", Quote, CrashInfo);
|
2013-09-20 04:32:16 +08:00
|
|
|
OS << " ||";
|
2014-10-22 01:24:44 +08:00
|
|
|
Fallback->Print(OS, Terminator, Quote, CrashInfo);
|
2013-09-20 04:32:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool ShouldFallback(int ExitCode) {
|
|
|
|
// FIXME: We really just want to fall back for internal errors, such
|
|
|
|
// as when some symbol cannot be mangled, when we should be able to
|
|
|
|
// parse something but can't, etc.
|
|
|
|
return ExitCode != 0;
|
|
|
|
}
|
|
|
|
|
2017-09-14 01:45:51 +08:00
|
|
|
int FallbackCommand::Execute(ArrayRef<llvm::Optional<StringRef>> Redirects,
|
2017-09-14 01:03:58 +08:00
|
|
|
std::string *ErrMsg, bool *ExecutionFailed) const {
|
2013-09-20 04:32:16 +08:00
|
|
|
int PrimaryStatus = Command::Execute(Redirects, ErrMsg, ExecutionFailed);
|
|
|
|
if (!ShouldFallback(PrimaryStatus))
|
|
|
|
return PrimaryStatus;
|
|
|
|
|
|
|
|
// Clear ExecutionFailed and ErrMsg before falling back.
|
|
|
|
if (ErrMsg)
|
|
|
|
ErrMsg->clear();
|
|
|
|
if (ExecutionFailed)
|
|
|
|
*ExecutionFailed = false;
|
|
|
|
|
2014-02-19 05:42:51 +08:00
|
|
|
const Driver &D = getCreator().getToolChain().getDriver();
|
2014-02-19 10:10:19 +08:00
|
|
|
D.Diag(diag::warn_drv_invoking_fallback) << Fallback->getExecutable();
|
2014-02-19 05:42:51 +08:00
|
|
|
|
2013-09-20 04:32:16 +08:00
|
|
|
int SecondaryStatus = Fallback->Execute(Redirects, ErrMsg, ExecutionFailed);
|
|
|
|
return SecondaryStatus;
|
|
|
|
}
|
|
|
|
|
2018-10-13 02:55:36 +08:00
|
|
|
ForceSuccessCommand::ForceSuccessCommand(
|
|
|
|
const Action &Source_, const Tool &Creator_, const char *Executable_,
|
|
|
|
const llvm::opt::ArgStringList &Arguments_, ArrayRef<InputInfo> Inputs)
|
clang-cl: Implement initial limited support for precompiled headers.
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
llvm-svn: 262420
2016-03-02 07:16:44 +08:00
|
|
|
: Command(Source_, Creator_, Executable_, Arguments_, Inputs) {}
|
|
|
|
|
|
|
|
void ForceSuccessCommand::Print(raw_ostream &OS, const char *Terminator,
|
|
|
|
bool Quote, CrashReportInfo *CrashInfo) const {
|
|
|
|
Command::Print(OS, "", Quote, CrashInfo);
|
|
|
|
OS << " || (exit 0)" << Terminator;
|
|
|
|
}
|
|
|
|
|
2017-09-14 01:45:51 +08:00
|
|
|
int ForceSuccessCommand::Execute(ArrayRef<llvm::Optional<StringRef>> Redirects,
|
clang-cl: Implement initial limited support for precompiled headers.
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
llvm-svn: 262420
2016-03-02 07:16:44 +08:00
|
|
|
std::string *ErrMsg,
|
|
|
|
bool *ExecutionFailed) const {
|
|
|
|
int Status = Command::Execute(Redirects, ErrMsg, ExecutionFailed);
|
|
|
|
(void)Status;
|
|
|
|
if (ExecutionFailed)
|
|
|
|
*ExecutionFailed = false;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-09-13 02:23:34 +08:00
|
|
|
void JobList::Print(raw_ostream &OS, const char *Terminator, bool Quote,
|
2014-10-22 01:24:44 +08:00
|
|
|
CrashReportInfo *CrashInfo) const {
|
2014-10-03 09:04:53 +08:00
|
|
|
for (const auto &Job : *this)
|
2014-10-22 01:24:44 +08:00
|
|
|
Job.Print(OS, Terminator, Quote, CrashInfo);
|
2013-09-13 02:23:34 +08:00
|
|
|
}
|
|
|
|
|
2014-09-05 00:04:28 +08:00
|
|
|
void JobList::clear() { Jobs.clear(); }
|