2009-03-18 06:07:58 +08:00
|
|
|
//===--- Tools.h - Tool Implementations -------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:25:19 +08:00
|
|
|
#ifndef LLVM_CLANG_LIB_DRIVER_TOOLS_H
|
|
|
|
#define LLVM_CLANG_LIB_DRIVER_TOOLS_H
|
2009-03-18 06:07:58 +08:00
|
|
|
|
|
|
|
#include "clang/Driver/Tool.h"
|
2009-03-30 01:08:39 +08:00
|
|
|
#include "clang/Driver/Types.h"
|
2009-03-18 16:07:30 +08:00
|
|
|
#include "clang/Driver/Util.h"
|
2011-05-16 21:35:02 +08:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2013-06-15 01:17:23 +08:00
|
|
|
#include "llvm/Option/Option.h"
|
2009-03-18 06:07:58 +08:00
|
|
|
#include "llvm/Support/Compiler.h"
|
|
|
|
|
|
|
|
namespace clang {
|
2012-06-20 14:18:46 +08:00
|
|
|
class ObjCRuntime;
|
|
|
|
|
2009-03-18 06:07:58 +08:00
|
|
|
namespace driver {
|
2013-09-20 04:32:16 +08:00
|
|
|
class Command;
|
2009-04-18 08:34:01 +08:00
|
|
|
class Driver;
|
|
|
|
|
2009-03-27 00:23:12 +08:00
|
|
|
namespace toolchains {
|
2014-01-16 16:48:16 +08:00
|
|
|
class MachO;
|
2009-03-27 00:23:12 +08:00
|
|
|
}
|
|
|
|
|
2009-03-18 06:18:43 +08:00
|
|
|
namespace tools {
|
2014-06-27 03:59:02 +08:00
|
|
|
|
|
|
|
namespace visualstudio {
|
|
|
|
class Compile;
|
|
|
|
}
|
|
|
|
|
2013-06-15 01:17:23 +08:00
|
|
|
using llvm::opt::ArgStringList;
|
2009-03-18 06:07:58 +08:00
|
|
|
|
2010-05-21 05:30:13 +08:00
|
|
|
/// \brief Clang compiler tool.
|
2010-05-12 04:16:05 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Clang : public Tool {
|
2012-12-18 08:31:10 +08:00
|
|
|
public:
|
2013-06-17 21:59:19 +08:00
|
|
|
static const char *getBaseInputName(const llvm::opt::ArgList &Args,
|
2012-11-23 14:14:39 +08:00
|
|
|
const InputInfoList &Inputs);
|
2013-06-17 21:59:19 +08:00
|
|
|
static const char *getBaseInputStem(const llvm::opt::ArgList &Args,
|
2012-11-23 14:14:39 +08:00
|
|
|
const InputInfoList &Inputs);
|
2013-06-17 21:59:19 +08:00
|
|
|
static const char *getDependencyFileName(const llvm::opt::ArgList &Args,
|
2012-11-23 14:14:39 +08:00
|
|
|
const InputInfoList &Inputs);
|
|
|
|
|
2012-12-18 08:31:10 +08:00
|
|
|
private:
|
2013-06-17 21:59:19 +08:00
|
|
|
void AddPreprocessingOptions(Compilation &C, const JobAction &JA,
|
2011-11-06 08:40:05 +08:00
|
|
|
const Driver &D,
|
2013-06-17 21:59:19 +08:00
|
|
|
const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs,
|
2009-04-09 07:54:23 +08:00
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs) const;
|
|
|
|
|
2013-10-31 17:32:33 +08:00
|
|
|
void AddAArch64TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2013-06-17 21:59:19 +08:00
|
|
|
void AddARMTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs,
|
2011-03-18 01:10:06 +08:00
|
|
|
bool KernelOrKext) const;
|
2014-03-29 23:09:45 +08:00
|
|
|
void AddARM64TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2013-06-17 21:59:19 +08:00
|
|
|
void AddMIPSTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2014-07-28 21:17:52 +08:00
|
|
|
void AddPPCTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2013-06-17 21:59:19 +08:00
|
|
|
void AddR600TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddSparcTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2013-07-20 00:51:51 +08:00
|
|
|
void AddSystemZTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2013-06-17 21:59:19 +08:00
|
|
|
void AddX86TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddHexagonTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2009-09-10 06:33:08 +08:00
|
|
|
|
2012-06-20 14:18:46 +08:00
|
|
|
enum RewriteKind { RK_None, RK_Fragile, RK_NonFragile };
|
|
|
|
|
2013-06-17 21:59:19 +08:00
|
|
|
ObjCRuntime AddObjCRuntimeArgs(const llvm::opt::ArgList &args,
|
|
|
|
llvm::opt::ArgStringList &cmdArgs,
|
2012-06-20 14:18:46 +08:00
|
|
|
RewriteKind rewrite) const;
|
|
|
|
|
2013-08-08 08:17:41 +08:00
|
|
|
void AddClangCLArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
|
2014-06-27 03:59:02 +08:00
|
|
|
visualstudio::Compile *getCLFallback() const;
|
|
|
|
|
|
|
|
mutable std::unique_ptr<visualstudio::Compile> CLFallback;
|
|
|
|
|
2009-03-18 06:07:58 +08:00
|
|
|
public:
|
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
|
|
|
Clang(const ToolChain &TC) : Tool("clang", "clang frontend", TC, RF_Full) {}
|
2009-03-18 06:07:58 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasGoodDiagnostics() const override { return true; }
|
|
|
|
bool hasIntegratedAssembler() const override { return true; }
|
|
|
|
bool hasIntegratedCPP() const override { return true; }
|
Reapply "Change -save-temps to emit unoptimized bitcode files."
This reapplies r224503 along with a fix for compiling Fortran by having the
clang driver invoke gcc (see r224546, where it was reverted). I have added
a testcase for that as well.
Original commit message:
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
llvm-svn: 224688
2014-12-21 15:00:00 +08:00
|
|
|
bool canEmitIR() const override { return true; }
|
2009-03-18 14:00:36 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2010-05-21 05:30:13 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Clang integrated assembler tool.
|
|
|
|
class LLVM_LIBRARY_VISIBILITY ClangAs : public Tool {
|
|
|
|
public:
|
2010-05-22 08:37:18 +08:00
|
|
|
ClangAs(const ToolChain &TC) : Tool("clang::as",
|
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
|
|
|
"clang integrated assembler", TC,
|
|
|
|
RF_Full) {}
|
2015-01-31 01:35:23 +08:00
|
|
|
void AddMIPSTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasGoodDiagnostics() const override { return true; }
|
|
|
|
bool hasIntegratedAssembler() const override { return false; }
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2010-05-21 05:30:13 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-03-18 06:07:58 +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
|
|
|
/// \brief Base class for all GNU tools that provide the same behavior when
|
|
|
|
/// it comes to response files support
|
|
|
|
class GnuTool : public Tool {
|
|
|
|
virtual void anchor();
|
|
|
|
|
|
|
|
public:
|
|
|
|
GnuTool(const char *Name, const char *ShortName, const ToolChain &TC)
|
|
|
|
: Tool(Name, ShortName, TC, RF_Full, llvm::sys::WEM_CurrentCodePage) {}
|
|
|
|
};
|
|
|
|
|
2009-03-18 06:45:24 +08:00
|
|
|
/// gcc - Generic GCC tool implementations.
|
|
|
|
namespace gcc {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Common : public GnuTool {
|
2009-03-18 06:07:58 +08:00
|
|
|
public:
|
2010-05-22 08:37:18 +08:00
|
|
|
Common(const char *Name, const char *ShortName,
|
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
|
|
|
const ToolChain &TC) : GnuTool(Name, ShortName, TC) {}
|
2009-03-18 14:00:36 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-03-18 16:07:30 +08:00
|
|
|
|
|
|
|
/// RenderExtraToolArgs - Render any arguments necessary to force
|
|
|
|
/// the particular tool mode.
|
2013-06-17 21:59:19 +08:00
|
|
|
virtual void
|
|
|
|
RenderExtraToolArgs(const JobAction &JA,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const = 0;
|
2009-03-18 06:07:58 +08:00
|
|
|
};
|
|
|
|
|
2010-05-12 04:16:05 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Preprocess : public Common {
|
2009-03-18 06:07:58 +08:00
|
|
|
public:
|
2010-05-22 08:37:18 +08:00
|
|
|
Preprocess(const ToolChain &TC) : Common("gcc::Preprocess",
|
|
|
|
"gcc preprocessor", TC) {}
|
2009-03-18 16:07:30 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasGoodDiagnostics() const override { return true; }
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2009-03-18 16:07:30 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void RenderExtraToolArgs(const JobAction &JA,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const override;
|
2009-03-18 16:07:30 +08:00
|
|
|
};
|
|
|
|
|
2010-05-12 04:16:05 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Compile : public Common {
|
2009-03-18 06:07:58 +08:00
|
|
|
public:
|
2010-05-22 08:37:18 +08:00
|
|
|
Compile(const ToolChain &TC) : Common("gcc::Compile",
|
|
|
|
"gcc frontend", TC) {}
|
2009-03-18 06:07:58 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasGoodDiagnostics() const override { return true; }
|
|
|
|
bool hasIntegratedCPP() const override { return true; }
|
2009-03-18 14:00:36 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void RenderExtraToolArgs(const JobAction &JA,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const override;
|
2009-03-18 06:07:58 +08:00
|
|
|
};
|
|
|
|
|
2010-05-12 04:16:05 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public Common {
|
2009-03-18 06:07:58 +08:00
|
|
|
public:
|
2010-05-22 08:37:18 +08:00
|
|
|
Link(const ToolChain &TC) : Common("gcc::Link",
|
|
|
|
"linker (via gcc)", TC) {}
|
2009-03-18 06:07:58 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2009-03-18 14:00:36 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void RenderExtraToolArgs(const JobAction &JA,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const override;
|
2009-03-18 06:07:58 +08:00
|
|
|
};
|
2009-03-18 06:45:24 +08:00
|
|
|
} // end namespace gcc
|
2009-03-18 06:07:58 +08:00
|
|
|
|
2011-12-13 05:14:55 +08:00
|
|
|
namespace hexagon {
|
|
|
|
// For Hexagon, we do not need to instantiate tools for PreProcess, PreCompile and Compile.
|
|
|
|
// We simply use "clang -cc1" for those actions.
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2011-12-13 05:14:55 +08:00
|
|
|
public:
|
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
|
|
|
Assemble(const ToolChain &TC) : GnuTool("hexagon::Assemble",
|
2011-12-13 05:14:55 +08:00
|
|
|
"hexagon-as", TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2011-12-13 05:14:55 +08:00
|
|
|
|
2014-03-14 14:06:19 +08:00
|
|
|
void RenderExtraToolArgs(const JobAction &JA,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2011-12-13 05:14:55 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2011-12-13 05:14:55 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : GnuTool("hexagon::Link",
|
2011-12-13 05:14:55 +08:00
|
|
|
"hexagon-ld", TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2011-12-13 05:14:55 +08:00
|
|
|
|
|
|
|
virtual void RenderExtraToolArgs(const JobAction &JA,
|
2013-06-17 21:59:19 +08:00
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2011-12-13 05:14:55 +08:00
|
|
|
};
|
|
|
|
} // end namespace hexagon.
|
|
|
|
|
2013-12-12 21:27:11 +08:00
|
|
|
namespace arm {
|
2013-12-12 23:48:19 +08:00
|
|
|
StringRef getARMTargetCPU(const llvm::opt::ArgList &Args,
|
|
|
|
const llvm::Triple &Triple);
|
2013-12-12 21:27:11 +08:00
|
|
|
const char* getARMCPUForMArch(const llvm::opt::ArgList &Args,
|
|
|
|
const llvm::Triple &Triple);
|
|
|
|
const char* getLLVMArchSuffixForARM(StringRef CPU);
|
2015-01-29 07:30:39 +08:00
|
|
|
|
|
|
|
void appendEBLinkFlags(const llvm::opt::ArgList &Args, ArgStringList &CmdArgs, const llvm::Triple &Triple);
|
2013-12-12 21:27:11 +08:00
|
|
|
}
|
2011-12-13 05:14:55 +08:00
|
|
|
|
2014-02-12 11:21:20 +08:00
|
|
|
namespace mips {
|
2014-07-16 20:29:22 +08:00
|
|
|
void getMipsCPUAndABI(const llvm::opt::ArgList &Args,
|
|
|
|
const llvm::Triple &Triple, StringRef &CPUName,
|
|
|
|
StringRef &ABIName);
|
2014-02-12 11:21:20 +08:00
|
|
|
bool hasMipsAbiArg(const llvm::opt::ArgList &Args, const char *Value);
|
2014-08-13 22:34:14 +08:00
|
|
|
bool isUCLibc(const llvm::opt::ArgList &Args);
|
2014-07-10 22:40:57 +08:00
|
|
|
bool isNaN2008(const llvm::opt::ArgList &Args, const llvm::Triple &Triple);
|
2014-07-16 19:52:23 +08:00
|
|
|
bool isFPXXDefault(const llvm::Triple &Triple, StringRef CPUName,
|
|
|
|
StringRef ABIName);
|
2014-02-12 11:21:20 +08:00
|
|
|
}
|
|
|
|
|
2014-07-28 21:17:52 +08:00
|
|
|
namespace ppc {
|
|
|
|
bool hasPPCAbiArg(const llvm::opt::ArgList &Args, const char *Value);
|
|
|
|
}
|
|
|
|
|
2015-03-26 19:13:44 +08:00
|
|
|
/// cloudabi -- Directly call GNU Binutils linker
|
|
|
|
namespace cloudabi {
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
|
|
|
public:
|
|
|
|
Link(const ToolChain &TC) : GnuTool("cloudabi::Link", "linker", TC) {}
|
|
|
|
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
} // end namespace cloudabi
|
|
|
|
|
2009-03-20 08:52:38 +08:00
|
|
|
namespace darwin {
|
2014-01-16 16:48:16 +08:00
|
|
|
llvm::Triple::ArchType getArchTypeForMachOArchName(StringRef Str);
|
|
|
|
void setTripleTypeForMachOArchName(llvm::Triple &T, StringRef Str);
|
2012-11-01 02:51:07 +08:00
|
|
|
|
2014-01-16 16:48:16 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY MachOTool : public Tool {
|
2011-12-20 10:48:34 +08:00
|
|
|
virtual void anchor();
|
2009-09-10 02:36:20 +08:00
|
|
|
protected:
|
2014-01-16 16:48:16 +08:00
|
|
|
void AddMachOArch(const llvm::opt::ArgList &Args,
|
2013-06-17 21:59:19 +08:00
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2009-09-10 02:36:20 +08:00
|
|
|
|
2014-01-16 16:48:16 +08:00
|
|
|
const toolchains::MachO &getMachOToolChain() const {
|
|
|
|
return reinterpret_cast<const toolchains::MachO&>(getToolChain());
|
2009-09-10 02:36:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
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
|
|
|
MachOTool(
|
|
|
|
const char *Name, const char *ShortName, const ToolChain &TC,
|
|
|
|
ResponseFileSupport ResponseSupport = RF_None,
|
|
|
|
llvm::sys::WindowsEncodingMethod ResponseEncoding = llvm::sys::WEM_UTF8,
|
|
|
|
const char *ResponseFlag = "@")
|
|
|
|
: Tool(Name, ShortName, TC, ResponseSupport, ResponseEncoding,
|
|
|
|
ResponseFlag) {}
|
2009-09-10 02:36:20 +08:00
|
|
|
};
|
|
|
|
|
2014-01-16 16:48:16 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public MachOTool {
|
2009-03-21 00:06:39 +08:00
|
|
|
public:
|
2014-01-16 16:48:16 +08:00
|
|
|
Assemble(const ToolChain &TC) : MachOTool("darwin::Assemble",
|
|
|
|
"assembler", TC) {}
|
2009-03-21 00:06:39 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2009-03-21 00:06:39 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-03-27 00:23:12 +08:00
|
|
|
};
|
|
|
|
|
2014-01-16 16:48:16 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public MachOTool {
|
2012-10-03 02:02:50 +08:00
|
|
|
bool NeedsTempPath(const InputInfoList &Inputs) const;
|
2013-06-17 21:59:19 +08:00
|
|
|
void AddLinkArgs(Compilation &C, const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs,
|
|
|
|
const InputInfoList &Inputs) const;
|
2009-03-27 00:23:12 +08:00
|
|
|
|
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : MachOTool("darwin::Link", "linker", TC,
|
|
|
|
RF_FileList, llvm::sys::WEM_UTF8,
|
|
|
|
"-filelist") {}
|
2009-03-27 00:23:12 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2009-03-27 00:23:12 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-03-21 00:06:39 +08:00
|
|
|
};
|
|
|
|
|
2014-01-16 16:48:16 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Lipo : public MachOTool {
|
2009-03-20 08:52:38 +08:00
|
|
|
public:
|
2014-01-16 16:48:16 +08:00
|
|
|
Lipo(const ToolChain &TC) : MachOTool("darwin::Lipo", "lipo", TC) {}
|
2009-03-20 08:52:38 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2009-03-20 08:52:38 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2010-06-05 02:28:36 +08:00
|
|
|
};
|
|
|
|
|
2014-01-16 16:48:16 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Dsymutil : public MachOTool {
|
2010-06-05 02:28:36 +08:00
|
|
|
public:
|
2014-01-16 16:48:16 +08:00
|
|
|
Dsymutil(const ToolChain &TC) : MachOTool("darwin::Dsymutil",
|
|
|
|
"dsymutil", TC) {}
|
2010-06-05 02:28:36 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isDsymutilJob() const override { return true; }
|
2010-06-05 02:28:36 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-06-30 04:52:51 +08:00
|
|
|
};
|
2011-08-24 01:56:55 +08:00
|
|
|
|
2014-01-16 16:48:16 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY VerifyDebug : public MachOTool {
|
2011-08-24 01:56:55 +08:00
|
|
|
public:
|
2014-01-16 16:48:16 +08:00
|
|
|
VerifyDebug(const ToolChain &TC) : MachOTool("darwin::VerifyDebug",
|
|
|
|
"dwarfdump", TC) {}
|
2011-08-24 01:56:55 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2011-08-24 01:56:55 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2011-08-24 01:56:55 +08:00
|
|
|
};
|
|
|
|
|
2009-06-30 04:52:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// openbsd -- Directly call GNU Binutils assembler and linker
|
|
|
|
namespace openbsd {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2009-06-30 04:52:51 +08:00
|
|
|
public:
|
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
|
|
|
Assemble(const ToolChain &TC) : GnuTool("openbsd::Assemble", "assembler",
|
2010-05-22 08:37:18 +08:00
|
|
|
TC) {}
|
2009-06-30 04:52:51 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2009-06-30 04:52:51 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-06-30 04:52:51 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2009-06-30 04:52:51 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : GnuTool("openbsd::Link", "linker", TC) {}
|
2009-06-30 04:52:51 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2009-06-30 04:52:51 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-03-20 08:52:38 +08:00
|
|
|
};
|
2009-08-22 09:06:46 +08:00
|
|
|
} // end namespace openbsd
|
2009-03-20 08:52:38 +08:00
|
|
|
|
2012-08-09 07:57:20 +08:00
|
|
|
/// bitrig -- Directly call GNU Binutils assembler and linker
|
|
|
|
namespace bitrig {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2012-08-09 07:57:20 +08:00
|
|
|
public:
|
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
|
|
|
Assemble(const ToolChain &TC) : GnuTool("bitrig::Assemble", "assembler",
|
2012-08-09 07:57:20 +08:00
|
|
|
TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2012-08-09 07:57:20 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2012-08-09 07:57:20 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2012-08-09 07:57:20 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : GnuTool("bitrig::Link", "linker", TC) {}
|
2012-08-09 07:57:20 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2012-08-09 07:57:20 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2012-08-09 07:57:20 +08:00
|
|
|
};
|
|
|
|
} // end namespace bitrig
|
|
|
|
|
2009-04-01 01:45:15 +08:00
|
|
|
/// freebsd -- Directly call GNU Binutils assembler and linker
|
|
|
|
namespace freebsd {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2009-04-01 01:45:15 +08:00
|
|
|
public:
|
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
|
|
|
Assemble(const ToolChain &TC) : GnuTool("freebsd::Assemble", "assembler",
|
2010-05-22 08:37:18 +08:00
|
|
|
TC) {}
|
2009-04-01 01:45:15 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2009-04-01 01:45:15 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-04-02 03:36:32 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2009-04-02 03:36:32 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : GnuTool("freebsd::Link", "linker", TC) {}
|
2009-04-02 03:36:32 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2009-04-02 03:36:32 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-04-01 01:45:15 +08:00
|
|
|
};
|
2009-08-22 09:06:46 +08:00
|
|
|
} // end namespace freebsd
|
|
|
|
|
2011-02-03 02:59:27 +08:00
|
|
|
/// netbsd -- Directly call GNU Binutils assembler and linker
|
|
|
|
namespace netbsd {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2011-05-16 21:35:02 +08:00
|
|
|
|
2011-02-03 02:59:27 +08:00
|
|
|
public:
|
2012-01-27 06:27:52 +08:00
|
|
|
Assemble(const ToolChain &TC)
|
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
|
|
|
: GnuTool("netbsd::Assemble", "assembler", TC) {}
|
2011-02-03 02:59:27 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2011-02-03 02:59:27 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2011-02-03 02:59:27 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2011-05-16 21:35:02 +08:00
|
|
|
|
2011-02-03 02:59:27 +08:00
|
|
|
public:
|
2012-01-27 06:27:52 +08:00
|
|
|
Link(const ToolChain &TC)
|
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
|
|
|
: GnuTool("netbsd::Link", "linker", TC) {}
|
2011-02-03 02:59:27 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2011-02-03 02:59:27 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2011-02-03 02:59:27 +08:00
|
|
|
};
|
|
|
|
} // end namespace netbsd
|
|
|
|
|
2013-03-29 03:04:25 +08:00
|
|
|
/// Directly call GNU Binutils' assembler and linker.
|
|
|
|
namespace gnutools {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2010-08-10 08:25:48 +08:00
|
|
|
public:
|
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
|
|
|
Assemble(const ToolChain &TC) : GnuTool("GNU::Assemble", "assembler", TC) {}
|
2010-08-10 08:25:48 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2010-08-10 08:25:48 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2010-11-08 04:14:31 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2010-11-08 04:14:31 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : GnuTool("GNU::Link", "linker", TC) {}
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2010-08-10 08:25:48 +08:00
|
|
|
};
|
|
|
|
}
|
2015-03-31 04:31:33 +08:00
|
|
|
|
|
|
|
namespace nacltools {
|
|
|
|
class LLVM_LIBRARY_VISIBILITY AssembleARM : public gnutools::Assemble {
|
|
|
|
public:
|
|
|
|
AssembleARM(const ToolChain &TC) : gnutools::Assemble(TC) {}
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public Tool {
|
|
|
|
public:
|
|
|
|
Link(const ToolChain &TC) : Tool("NaCl::Link", "linker", TC) {}
|
|
|
|
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2010-07-08 00:01:42 +08:00
|
|
|
/// minix -- Directly call GNU Binutils assembler and linker
|
|
|
|
namespace minix {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2010-07-08 00:01:42 +08:00
|
|
|
public:
|
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
|
|
|
Assemble(const ToolChain &TC) : GnuTool("minix::Assemble", "assembler",
|
2010-07-08 00:01:42 +08:00
|
|
|
TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2010-07-08 00:01:42 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2010-07-08 00:01:42 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2010-07-08 00:01:42 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : GnuTool("minix::Link", "linker", TC) {}
|
2010-07-08 00:01:42 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2010-07-08 00:01:42 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2010-07-08 00:01:42 +08:00
|
|
|
};
|
|
|
|
} // end namespace minix
|
|
|
|
|
2012-02-15 21:39:01 +08:00
|
|
|
/// solaris -- Directly call Solaris assembler and linker
|
|
|
|
namespace solaris {
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public Tool {
|
|
|
|
public:
|
|
|
|
Assemble(const ToolChain &TC) : Tool("solaris::Assemble", "assembler",
|
|
|
|
TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2012-02-15 21:39:01 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2012-02-15 21:39:01 +08:00
|
|
|
};
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public Tool {
|
|
|
|
public:
|
|
|
|
Link(const ToolChain &TC) : Tool("solaris::Link", "linker", TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2012-02-15 21:39:01 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2012-02-15 21:39:01 +08:00
|
|
|
};
|
2012-02-16 00:25:46 +08:00
|
|
|
} // end namespace solaris
|
2012-02-15 21:39:01 +08:00
|
|
|
|
2009-05-03 02:28:39 +08:00
|
|
|
/// dragonfly -- Directly call GNU Binutils assembler and linker
|
|
|
|
namespace dragonfly {
|
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
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public GnuTool {
|
2009-05-03 02:28:39 +08:00
|
|
|
public:
|
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
|
|
|
Assemble(const ToolChain &TC) : GnuTool("dragonfly::Assemble", "assembler",
|
2010-05-22 08:37:18 +08:00
|
|
|
TC) {}
|
2009-05-03 02:28:39 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
2009-05-03 02:28:39 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-05-03 02:28:39 +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
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public GnuTool {
|
2009-05-03 02:28:39 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : GnuTool("dragonfly::Link", "linker", TC) {}
|
2009-05-03 02:28:39 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2009-05-03 02:28:39 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2009-05-03 02:28:39 +08:00
|
|
|
};
|
2009-08-22 09:06:46 +08:00
|
|
|
} // end namespace dragonfly
|
2009-05-03 02:28:39 +08:00
|
|
|
|
2014-06-27 03:59:02 +08:00
|
|
|
/// Visual studio tools.
|
2010-08-22 05:55:07 +08:00
|
|
|
namespace visualstudio {
|
2013-09-20 04:32:16 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public Tool {
|
2010-08-22 05:55:07 +08:00
|
|
|
public:
|
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
|
|
|
Link(const ToolChain &TC) : Tool("visualstudio::Link", "linker", TC,
|
|
|
|
RF_Full, llvm::sys::WEM_UTF16) {}
|
2010-08-22 05:55:07 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
2010-08-22 05:55:07 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2010-08-22 05:55:07 +08:00
|
|
|
};
|
2013-09-20 04:32:16 +08:00
|
|
|
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Compile : public Tool {
|
|
|
|
public:
|
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
|
|
|
Compile(const ToolChain &TC) : Tool("visualstudio::Compile", "compiler", TC,
|
|
|
|
RF_Full, llvm::sys::WEM_UTF16) {}
|
2013-09-20 04:32:16 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedAssembler() const override { return true; }
|
|
|
|
bool hasIntegratedCPP() const override { return true; }
|
|
|
|
bool isLinkJob() const override { return false; }
|
2013-09-20 04:32:16 +08:00
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2013-09-20 04:32:16 +08:00
|
|
|
|
2014-09-05 00:04:28 +08:00
|
|
|
std::unique_ptr<Command> GetCommand(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const;
|
2013-09-20 04:32:16 +08:00
|
|
|
};
|
2010-08-22 05:55:07 +08:00
|
|
|
} // end namespace visualstudio
|
|
|
|
|
2013-12-12 19:55:52 +08:00
|
|
|
namespace arm {
|
|
|
|
StringRef getARMFloatABI(const Driver &D, const llvm::opt::ArgList &Args,
|
2014-10-03 17:11:41 +08:00
|
|
|
const llvm::Triple &Triple);
|
2013-12-12 19:55:52 +08:00
|
|
|
}
|
2013-10-11 18:29:40 +08:00
|
|
|
namespace XCore {
|
|
|
|
// For XCore, we do not need to instantiate tools for PreProcess, PreCompile and Compile.
|
|
|
|
// We simply use "clang -cc1" for those actions.
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public Tool {
|
|
|
|
public:
|
|
|
|
Assemble(const ToolChain &TC) : Tool("XCore::Assemble",
|
|
|
|
"XCore-as", TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2013-10-11 18:29:40 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public Tool {
|
|
|
|
public:
|
|
|
|
Link(const ToolChain &TC) : Tool("XCore::Link",
|
|
|
|
"XCore-ld", TC) {}
|
|
|
|
|
2014-03-14 14:02:07 +08:00
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
2013-10-11 18:29:40 +08:00
|
|
|
};
|
|
|
|
} // end namespace XCore.
|
|
|
|
|
2014-10-24 11:13:37 +08:00
|
|
|
namespace CrossWindows {
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Assemble : public Tool {
|
|
|
|
public:
|
|
|
|
Assemble(const ToolChain &TC) : Tool("CrossWindows::Assemble", "as", TC) { }
|
|
|
|
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Link : public Tool {
|
|
|
|
public:
|
|
|
|
Link(const ToolChain &TC) : Tool("CrossWindows::Link", "ld", TC, RF_Full) {}
|
|
|
|
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
bool isLinkJob() const override { return true; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
}
|
2013-10-11 18:29:40 +08:00
|
|
|
|
2009-03-18 06:07:58 +08:00
|
|
|
} // end namespace toolchains
|
|
|
|
} // end namespace driver
|
|
|
|
} // end namespace clang
|
|
|
|
|
2014-08-14 00:25:19 +08:00
|
|
|
#endif
|