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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217792 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 7 insertions, 5 deletions

diff --git a/lib/Driver/Tool.cpp b/lib/Driver/Tool.cpp
index b93864ff8b..7142e822f1 100644
--- a/lib/Driver/Tool.cpp
+++ b/lib/Driver/Tool.cpp
@@ -11,11 +11,13 @@
 
 using namespace clang::driver;
 
-Tool::Tool(const char *_Name, const char *_ShortName,
-           const ToolChain &TC) : Name(_Name), ShortName(_ShortName),
-                                  TheToolChain(TC)
-{
-}
+Tool::Tool(const char *_Name, const char *_ShortName, const ToolChain &TC,
+           ResponseFileSupport _ResponseSupport,
+           llvm::sys::WindowsEncodingMethod _ResponseEncoding,
+           const char *_ResponseFlag)
+    : Name(_Name), ShortName(_ShortName), TheToolChain(TC),
+      ResponseSupport(_ResponseSupport), ResponseEncoding(_ResponseEncoding),
+      ResponseFlag(_ResponseFlag) {}
 
 Tool::~Tool() {
 }