[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
//===--- MinGW.cpp - MinGWToolChain Implementation ------------------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "MinGW.h"
|
|
|
|
#include "InputInfo.h"
|
|
|
|
#include "CommonArgs.h"
|
2018-10-13 04:15:51 +08:00
|
|
|
#include "clang/Config/config.h"
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
#include "clang/Driver/Compilation.h"
|
|
|
|
#include "clang/Driver/Driver.h"
|
|
|
|
#include "clang/Driver/DriverDiagnostic.h"
|
|
|
|
#include "clang/Driver/Options.h"
|
2018-10-02 04:53:25 +08:00
|
|
|
#include "clang/Driver/SanitizerArgs.h"
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
#include "llvm/Option/ArgList.h"
|
|
|
|
#include "llvm/Support/FileSystem.h"
|
|
|
|
#include "llvm/Support/Path.h"
|
2020-04-29 15:34:08 +08:00
|
|
|
#include "llvm/Support/VirtualFileSystem.h"
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
#include <system_error>
|
|
|
|
|
|
|
|
using namespace clang::diag;
|
|
|
|
using namespace clang::driver;
|
|
|
|
using namespace clang;
|
|
|
|
using namespace llvm::opt;
|
|
|
|
|
|
|
|
/// MinGW Tools
|
|
|
|
void tools::MinGW::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const ArgList &Args,
|
|
|
|
const char *LinkingOutput) const {
|
|
|
|
claimNoWarnArgs(Args);
|
|
|
|
ArgStringList CmdArgs;
|
|
|
|
|
|
|
|
if (getToolChain().getArch() == llvm::Triple::x86) {
|
|
|
|
CmdArgs.push_back("--32");
|
|
|
|
} else if (getToolChain().getArch() == llvm::Triple::x86_64) {
|
|
|
|
CmdArgs.push_back("--64");
|
|
|
|
}
|
|
|
|
|
|
|
|
Args.AddAllArgValues(CmdArgs, options::OPT_Wa_COMMA, options::OPT_Xassembler);
|
|
|
|
|
|
|
|
CmdArgs.push_back("-o");
|
|
|
|
CmdArgs.push_back(Output.getFilename());
|
|
|
|
|
|
|
|
for (const auto &II : Inputs)
|
|
|
|
CmdArgs.push_back(II.getFilename());
|
|
|
|
|
|
|
|
const char *Exec = Args.MakeArgString(getToolChain().GetProgramPath("as"));
|
2019-08-15 07:04:18 +08:00
|
|
|
C.addCommand(std::make_unique<Command>(JA, *this, Exec, CmdArgs, Inputs));
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_gsplit_dwarf))
|
|
|
|
SplitDebugInfo(getToolChain(), C, *this, JA, Args, Output,
|
2019-03-27 19:00:03 +08:00
|
|
|
SplitDebugName(Args, Inputs[0], Output));
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void tools::MinGW::Linker::AddLibGCC(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
|
|
|
if (Args.hasArg(options::OPT_mthreads))
|
|
|
|
CmdArgs.push_back("-lmingwthrd");
|
|
|
|
CmdArgs.push_back("-lmingw32");
|
|
|
|
|
|
|
|
// Make use of compiler-rt if --rtlib option is used
|
|
|
|
ToolChain::RuntimeLibType RLT = getToolChain().GetRuntimeLibType(Args);
|
|
|
|
if (RLT == ToolChain::RLT_Libgcc) {
|
|
|
|
bool Static = Args.hasArg(options::OPT_static_libgcc) ||
|
|
|
|
Args.hasArg(options::OPT_static);
|
|
|
|
bool Shared = Args.hasArg(options::OPT_shared);
|
|
|
|
bool CXX = getToolChain().getDriver().CCCIsCXX();
|
|
|
|
|
|
|
|
if (Static || (!CXX && !Shared)) {
|
|
|
|
CmdArgs.push_back("-lgcc");
|
|
|
|
CmdArgs.push_back("-lgcc_eh");
|
|
|
|
} else {
|
|
|
|
CmdArgs.push_back("-lgcc_s");
|
|
|
|
CmdArgs.push_back("-lgcc");
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
AddRunTimeLibs(getToolChain(), getToolChain().getDriver(), CmdArgs, Args);
|
|
|
|
}
|
|
|
|
|
|
|
|
CmdArgs.push_back("-lmoldname");
|
|
|
|
CmdArgs.push_back("-lmingwex");
|
2017-09-26 03:24:45 +08:00
|
|
|
for (auto Lib : Args.getAllArgValues(options::OPT_l))
|
2018-07-10 18:46:45 +08:00
|
|
|
if (StringRef(Lib).startswith("msvcr") || StringRef(Lib).startswith("ucrt"))
|
2017-09-26 03:24:45 +08:00
|
|
|
return;
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
CmdArgs.push_back("-lmsvcrt");
|
|
|
|
}
|
|
|
|
|
|
|
|
void tools::MinGW::Linker::ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const ArgList &Args,
|
|
|
|
const char *LinkingOutput) const {
|
|
|
|
const ToolChain &TC = getToolChain();
|
|
|
|
const Driver &D = TC.getDriver();
|
2018-10-02 04:53:25 +08:00
|
|
|
const SanitizerArgs &Sanitize = TC.getSanitizerArgs();
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
|
|
|
|
ArgStringList CmdArgs;
|
|
|
|
|
|
|
|
// Silence warning for "clang -g foo.o -o foo"
|
|
|
|
Args.ClaimAllArgs(options::OPT_g_Group);
|
|
|
|
// and "clang -emit-llvm foo.o -o foo"
|
|
|
|
Args.ClaimAllArgs(options::OPT_emit_llvm);
|
|
|
|
// and for "clang -w foo.o -o foo". Other warning options are already
|
|
|
|
// handled somewhere else.
|
|
|
|
Args.ClaimAllArgs(options::OPT_w);
|
|
|
|
|
|
|
|
if (!D.SysRoot.empty())
|
|
|
|
CmdArgs.push_back(Args.MakeArgString("--sysroot=" + D.SysRoot));
|
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_s))
|
|
|
|
CmdArgs.push_back("-s");
|
|
|
|
|
|
|
|
CmdArgs.push_back("-m");
|
2017-08-14 03:42:17 +08:00
|
|
|
switch (TC.getArch()) {
|
|
|
|
case llvm::Triple::x86:
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
CmdArgs.push_back("i386pe");
|
2017-08-14 03:42:17 +08:00
|
|
|
break;
|
|
|
|
case llvm::Triple::x86_64:
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
CmdArgs.push_back("i386pep");
|
2017-08-14 03:42:17 +08:00
|
|
|
break;
|
|
|
|
case llvm::Triple::arm:
|
|
|
|
case llvm::Triple::thumb:
|
|
|
|
// FIXME: this is incorrect for WinCE
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
CmdArgs.push_back("thumb2pe");
|
2017-08-14 03:42:17 +08:00
|
|
|
break;
|
|
|
|
case llvm::Triple::aarch64:
|
|
|
|
CmdArgs.push_back("arm64pe");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unsupported target architecture.");
|
|
|
|
}
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_mwindows)) {
|
|
|
|
CmdArgs.push_back("--subsystem");
|
|
|
|
CmdArgs.push_back("windows");
|
|
|
|
} else if (Args.hasArg(options::OPT_mconsole)) {
|
|
|
|
CmdArgs.push_back("--subsystem");
|
|
|
|
CmdArgs.push_back("console");
|
|
|
|
}
|
|
|
|
|
2018-02-28 03:42:19 +08:00
|
|
|
if (Args.hasArg(options::OPT_mdll))
|
|
|
|
CmdArgs.push_back("--dll");
|
|
|
|
else if (Args.hasArg(options::OPT_shared))
|
|
|
|
CmdArgs.push_back("--shared");
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
if (Args.hasArg(options::OPT_static))
|
|
|
|
CmdArgs.push_back("-Bstatic");
|
2018-02-28 03:42:19 +08:00
|
|
|
else
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
CmdArgs.push_back("-Bdynamic");
|
2018-02-28 03:42:19 +08:00
|
|
|
if (Args.hasArg(options::OPT_mdll) || Args.hasArg(options::OPT_shared)) {
|
|
|
|
CmdArgs.push_back("-e");
|
|
|
|
if (TC.getArch() == llvm::Triple::x86)
|
|
|
|
CmdArgs.push_back("_DllMainCRTStartup@12");
|
|
|
|
else
|
|
|
|
CmdArgs.push_back("DllMainCRTStartup");
|
|
|
|
CmdArgs.push_back("--enable-auto-image-base");
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CmdArgs.push_back("-o");
|
2019-12-12 17:08:18 +08:00
|
|
|
const char *OutputFile = Output.getFilename();
|
|
|
|
// GCC implicitly adds an .exe extension if it is given an output file name
|
|
|
|
// that lacks an extension. However, GCC only does this when actually
|
|
|
|
// running on windows, not when operating as a cross compiler. As some users
|
|
|
|
// have come to rely on this behaviour, try to replicate it.
|
|
|
|
#ifdef _WIN32
|
|
|
|
if (!llvm::sys::path::has_extension(OutputFile))
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(Twine(OutputFile) + ".exe"));
|
|
|
|
else
|
|
|
|
CmdArgs.push_back(OutputFile);
|
|
|
|
#else
|
|
|
|
CmdArgs.push_back(OutputFile);
|
|
|
|
#endif
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
|
|
|
|
Args.AddAllArgs(CmdArgs, options::OPT_e);
|
|
|
|
// FIXME: add -N, -n flags
|
|
|
|
Args.AddLastArg(CmdArgs, options::OPT_r);
|
|
|
|
Args.AddLastArg(CmdArgs, options::OPT_s);
|
|
|
|
Args.AddLastArg(CmdArgs, options::OPT_t);
|
|
|
|
Args.AddAllArgs(CmdArgs, options::OPT_u_Group);
|
|
|
|
Args.AddLastArg(CmdArgs, options::OPT_Z_Flag);
|
|
|
|
|
|
|
|
if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {
|
|
|
|
if (Args.hasArg(options::OPT_shared) || Args.hasArg(options::OPT_mdll)) {
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(TC.GetFilePath("dllcrt2.o")));
|
|
|
|
} else {
|
|
|
|
if (Args.hasArg(options::OPT_municode))
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(TC.GetFilePath("crt2u.o")));
|
|
|
|
else
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(TC.GetFilePath("crt2.o")));
|
|
|
|
}
|
|
|
|
if (Args.hasArg(options::OPT_pg))
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(TC.GetFilePath("gcrt2.o")));
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(TC.GetFilePath("crtbegin.o")));
|
|
|
|
}
|
|
|
|
|
|
|
|
Args.AddAllArgs(CmdArgs, options::OPT_L);
|
|
|
|
TC.AddFilePathLibArgs(Args, CmdArgs);
|
2020-04-29 15:34:08 +08:00
|
|
|
|
|
|
|
// Add the compiler-rt library directories if they exist to help
|
|
|
|
// the linker find the various sanitizer, builtin, and profiling runtimes.
|
|
|
|
for (const auto &LibPath : TC.getLibraryPaths()) {
|
|
|
|
if (TC.getVFS().exists(LibPath))
|
|
|
|
CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
|
|
|
|
}
|
|
|
|
auto CRTPath = TC.getCompilerRTPath();
|
|
|
|
if (TC.getVFS().exists(CRTPath))
|
|
|
|
CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
|
|
|
|
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
|
|
|
|
|
|
|
|
// TODO: Add profile stuff here
|
|
|
|
|
2017-07-26 02:02:57 +08:00
|
|
|
if (TC.ShouldLinkCXXStdlib(Args)) {
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
|
|
|
|
!Args.hasArg(options::OPT_static);
|
|
|
|
if (OnlyLibstdcxxStatic)
|
|
|
|
CmdArgs.push_back("-Bstatic");
|
|
|
|
TC.AddCXXStdlibLibArgs(Args, CmdArgs);
|
|
|
|
if (OnlyLibstdcxxStatic)
|
|
|
|
CmdArgs.push_back("-Bdynamic");
|
|
|
|
}
|
|
|
|
|
2018-07-10 18:46:51 +08:00
|
|
|
bool HasWindowsApp = false;
|
|
|
|
for (auto Lib : Args.getAllArgValues(options::OPT_l)) {
|
|
|
|
if (Lib == "windowsapp") {
|
|
|
|
HasWindowsApp = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
if (!Args.hasArg(options::OPT_nostdlib)) {
|
|
|
|
if (!Args.hasArg(options::OPT_nodefaultlibs)) {
|
|
|
|
if (Args.hasArg(options::OPT_static))
|
|
|
|
CmdArgs.push_back("--start-group");
|
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_fstack_protector) ||
|
|
|
|
Args.hasArg(options::OPT_fstack_protector_strong) ||
|
|
|
|
Args.hasArg(options::OPT_fstack_protector_all)) {
|
|
|
|
CmdArgs.push_back("-lssp_nonshared");
|
|
|
|
CmdArgs.push_back("-lssp");
|
|
|
|
}
|
2018-10-23 14:33:22 +08:00
|
|
|
|
|
|
|
if (Args.hasFlag(options::OPT_fopenmp, options::OPT_fopenmp_EQ,
|
|
|
|
options::OPT_fno_openmp, false)) {
|
|
|
|
switch (TC.getDriver().getOpenMPRuntime(Args)) {
|
|
|
|
case Driver::OMPRT_OMP:
|
|
|
|
CmdArgs.push_back("-lomp");
|
|
|
|
break;
|
|
|
|
case Driver::OMPRT_IOMP5:
|
|
|
|
CmdArgs.push_back("-liomp5md");
|
|
|
|
break;
|
|
|
|
case Driver::OMPRT_GOMP:
|
|
|
|
CmdArgs.push_back("-lgomp");
|
|
|
|
break;
|
|
|
|
case Driver::OMPRT_Unknown:
|
|
|
|
// Already diagnosed.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
|
|
|
|
AddLibGCC(Args, CmdArgs);
|
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_pg))
|
|
|
|
CmdArgs.push_back("-lgmon");
|
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_pthread))
|
|
|
|
CmdArgs.push_back("-lpthread");
|
|
|
|
|
2018-10-02 04:53:25 +08:00
|
|
|
if (Sanitize.needsAsanRt()) {
|
|
|
|
// MinGW always links against a shared MSVCRT.
|
2019-03-12 10:12:48 +08:00
|
|
|
CmdArgs.push_back(TC.getCompilerRTArgString(Args, "asan_dynamic",
|
|
|
|
ToolChain::FT_Shared));
|
2018-10-02 04:53:25 +08:00
|
|
|
CmdArgs.push_back(
|
|
|
|
TC.getCompilerRTArgString(Args, "asan_dynamic_runtime_thunk"));
|
2019-04-15 18:57:09 +08:00
|
|
|
CmdArgs.push_back("--require-defined");
|
|
|
|
CmdArgs.push_back(TC.getArch() == llvm::Triple::x86
|
|
|
|
? "___asan_seh_interceptor"
|
|
|
|
: "__asan_seh_interceptor");
|
2018-10-02 04:53:25 +08:00
|
|
|
// Make sure the linker consider all object files from the dynamic
|
|
|
|
// runtime thunk.
|
2019-04-15 18:57:09 +08:00
|
|
|
CmdArgs.push_back("--whole-archive");
|
|
|
|
CmdArgs.push_back(
|
|
|
|
TC.getCompilerRTArgString(Args, "asan_dynamic_runtime_thunk"));
|
|
|
|
CmdArgs.push_back("--no-whole-archive");
|
2018-10-02 04:53:25 +08:00
|
|
|
}
|
|
|
|
|
2019-02-13 15:26:54 +08:00
|
|
|
TC.addProfileRTLibs(Args, CmdArgs);
|
|
|
|
|
2018-07-10 18:46:51 +08:00
|
|
|
if (!HasWindowsApp) {
|
|
|
|
// Add system libraries. If linking to libwindowsapp.a, that import
|
|
|
|
// library replaces all these and we shouldn't accidentally try to
|
|
|
|
// link to the normal desktop mode dlls.
|
|
|
|
if (Args.hasArg(options::OPT_mwindows)) {
|
|
|
|
CmdArgs.push_back("-lgdi32");
|
|
|
|
CmdArgs.push_back("-lcomdlg32");
|
|
|
|
}
|
|
|
|
CmdArgs.push_back("-ladvapi32");
|
|
|
|
CmdArgs.push_back("-lshell32");
|
|
|
|
CmdArgs.push_back("-luser32");
|
|
|
|
CmdArgs.push_back("-lkernel32");
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_static))
|
|
|
|
CmdArgs.push_back("--end-group");
|
2017-11-04 10:07:59 +08:00
|
|
|
else
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
AddLibGCC(Args, CmdArgs);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!Args.hasArg(options::OPT_nostartfiles)) {
|
|
|
|
// Add crtfastmath.o if available and fast math is enabled.
|
2019-11-08 09:14:51 +08:00
|
|
|
TC.addFastMathRuntimeIfAvailable(Args, CmdArgs);
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(TC.GetFilePath("crtend.o")));
|
|
|
|
}
|
|
|
|
}
|
2017-11-04 10:07:59 +08:00
|
|
|
const char *Exec = Args.MakeArgString(TC.GetLinkerPath());
|
2019-08-15 07:04:18 +08:00
|
|
|
C.addCommand(std::make_unique<Command>(JA, *this, Exec, CmdArgs, Inputs));
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Simplified from Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple.
|
|
|
|
static bool findGccVersion(StringRef LibDir, std::string &GccLibDir,
|
|
|
|
std::string &Ver) {
|
|
|
|
auto Version = toolchains::Generic_GCC::GCCVersion::Parse("0.0.0");
|
|
|
|
std::error_code EC;
|
|
|
|
for (llvm::sys::fs::directory_iterator LI(LibDir, EC), LE; !EC && LI != LE;
|
|
|
|
LI = LI.increment(EC)) {
|
|
|
|
StringRef VersionText = llvm::sys::path::filename(LI->path());
|
|
|
|
auto CandidateVersion =
|
|
|
|
toolchains::Generic_GCC::GCCVersion::Parse(VersionText);
|
|
|
|
if (CandidateVersion.Major == -1)
|
|
|
|
continue;
|
|
|
|
if (CandidateVersion <= Version)
|
|
|
|
continue;
|
2020-01-29 03:23:46 +08:00
|
|
|
Ver = std::string(VersionText);
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
GccLibDir = LI->path();
|
|
|
|
}
|
|
|
|
return Ver.size();
|
|
|
|
}
|
|
|
|
|
|
|
|
void toolchains::MinGW::findGccLibDir() {
|
|
|
|
llvm::SmallVector<llvm::SmallString<32>, 2> Archs;
|
|
|
|
Archs.emplace_back(getTriple().getArchName());
|
|
|
|
Archs[0] += "-w64-mingw32";
|
|
|
|
Archs.emplace_back("mingw32");
|
2018-04-18 16:47:26 +08:00
|
|
|
if (Arch.empty())
|
2020-01-29 03:23:46 +08:00
|
|
|
Arch = std::string(Archs[0].str());
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
// lib: Arch Linux, Ubuntu, Windows
|
|
|
|
// lib64: openSUSE Linux
|
|
|
|
for (StringRef CandidateLib : {"lib", "lib64"}) {
|
|
|
|
for (StringRef CandidateArch : Archs) {
|
|
|
|
llvm::SmallString<1024> LibDir(Base);
|
|
|
|
llvm::sys::path::append(LibDir, CandidateLib, "gcc", CandidateArch);
|
|
|
|
if (findGccVersion(LibDir, GccLibDir, Ver)) {
|
2020-01-29 03:23:46 +08:00
|
|
|
Arch = std::string(CandidateArch);
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-18 22:27:36 +08:00
|
|
|
llvm::ErrorOr<std::string> toolchains::MinGW::findGcc() {
|
|
|
|
llvm::SmallVector<llvm::SmallString<32>, 2> Gccs;
|
|
|
|
Gccs.emplace_back(getTriple().getArchName());
|
|
|
|
Gccs[0] += "-w64-mingw32-gcc";
|
|
|
|
Gccs.emplace_back("mingw32-gcc");
|
|
|
|
// Please do not add "gcc" here
|
|
|
|
for (StringRef CandidateGcc : Gccs)
|
|
|
|
if (llvm::ErrorOr<std::string> GPPName = llvm::sys::findProgramByName(CandidateGcc))
|
|
|
|
return GPPName;
|
|
|
|
return make_error_code(std::errc::no_such_file_or_directory);
|
|
|
|
}
|
|
|
|
|
2018-04-18 16:47:26 +08:00
|
|
|
llvm::ErrorOr<std::string> toolchains::MinGW::findClangRelativeSysroot() {
|
|
|
|
llvm::SmallVector<llvm::SmallString<32>, 2> Subdirs;
|
|
|
|
Subdirs.emplace_back(getTriple().str());
|
|
|
|
Subdirs.emplace_back(getTriple().getArchName());
|
|
|
|
Subdirs[1] += "-w64-mingw32";
|
2018-04-19 01:34:29 +08:00
|
|
|
StringRef ClangRoot =
|
|
|
|
llvm::sys::path::parent_path(getDriver().getInstalledDir());
|
|
|
|
StringRef Sep = llvm::sys::path::get_separator();
|
2018-04-18 16:47:26 +08:00
|
|
|
for (StringRef CandidateSubdir : Subdirs) {
|
2018-04-19 01:34:29 +08:00
|
|
|
if (llvm::sys::fs::is_directory(ClangRoot + Sep + CandidateSubdir)) {
|
2020-01-29 03:23:46 +08:00
|
|
|
Arch = std::string(CandidateSubdir);
|
2018-04-19 01:34:29 +08:00
|
|
|
return (ClangRoot + Sep + CandidateSubdir).str();
|
2018-04-18 16:47:26 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return make_error_code(std::errc::no_such_file_or_directory);
|
|
|
|
}
|
|
|
|
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
|
|
|
|
const ArgList &Args)
|
|
|
|
: ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args) {
|
|
|
|
getProgramPaths().push_back(getDriver().getInstalledDir());
|
|
|
|
|
|
|
|
if (getDriver().SysRoot.size())
|
|
|
|
Base = getDriver().SysRoot;
|
2018-04-18 16:47:26 +08:00
|
|
|
// Look for <clang-bin>/../<triplet>; if found, use <clang-bin>/.. as the
|
|
|
|
// base as it could still be a base for a gcc setup with libgcc.
|
|
|
|
else if (llvm::ErrorOr<std::string> TargetSubdir = findClangRelativeSysroot())
|
2020-01-29 03:23:46 +08:00
|
|
|
Base = std::string(llvm::sys::path::parent_path(TargetSubdir.get()));
|
2017-04-18 22:27:36 +08:00
|
|
|
else if (llvm::ErrorOr<std::string> GPPName = findGcc())
|
2020-01-29 03:23:46 +08:00
|
|
|
Base = std::string(llvm::sys::path::parent_path(
|
|
|
|
llvm::sys::path::parent_path(GPPName.get())));
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
else
|
2020-01-29 03:23:46 +08:00
|
|
|
Base = std::string(
|
|
|
|
llvm::sys::path::parent_path(getDriver().getInstalledDir()));
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
|
|
|
|
Base += llvm::sys::path::get_separator();
|
|
|
|
findGccLibDir();
|
|
|
|
// GccLibDir must precede Base/lib so that the
|
|
|
|
// correct crtbegin.o ,cetend.o would be found.
|
|
|
|
getFilePaths().push_back(GccLibDir);
|
|
|
|
getFilePaths().push_back(
|
|
|
|
(Base + Arch + llvm::sys::path::get_separator() + "lib").str());
|
|
|
|
getFilePaths().push_back(Base + "lib");
|
|
|
|
// openSUSE
|
|
|
|
getFilePaths().push_back(Base + Arch + "/sys-root/mingw/lib");
|
2018-10-13 04:15:51 +08:00
|
|
|
|
|
|
|
NativeLLVMSupport =
|
|
|
|
Args.getLastArgValue(options::OPT_fuse_ld_EQ, CLANG_DEFAULT_LINKER)
|
|
|
|
.equals_lower("lld");
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool toolchains::MinGW::IsIntegratedAssemblerDefault() const { return true; }
|
|
|
|
|
|
|
|
Tool *toolchains::MinGW::getTool(Action::ActionClass AC) const {
|
|
|
|
switch (AC) {
|
|
|
|
case Action::PreprocessJobClass:
|
|
|
|
if (!Preprocessor)
|
|
|
|
Preprocessor.reset(new tools::gcc::Preprocessor(*this));
|
|
|
|
return Preprocessor.get();
|
|
|
|
case Action::CompileJobClass:
|
|
|
|
if (!Compiler)
|
|
|
|
Compiler.reset(new tools::gcc::Compiler(*this));
|
|
|
|
return Compiler.get();
|
|
|
|
default:
|
|
|
|
return ToolChain::getTool(AC);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *toolchains::MinGW::buildAssembler() const {
|
|
|
|
return new tools::MinGW::Assembler(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *toolchains::MinGW::buildLinker() const {
|
|
|
|
return new tools::MinGW::Linker(*this);
|
|
|
|
}
|
|
|
|
|
2018-10-13 04:15:51 +08:00
|
|
|
bool toolchains::MinGW::HasNativeLLVMSupport() const {
|
|
|
|
return NativeLLVMSupport;
|
|
|
|
}
|
|
|
|
|
2017-08-04 07:55:42 +08:00
|
|
|
bool toolchains::MinGW::IsUnwindTablesDefault(const ArgList &Args) const {
|
2018-12-18 16:36:10 +08:00
|
|
|
Arg *ExceptionArg = Args.getLastArg(options::OPT_fsjlj_exceptions,
|
|
|
|
options::OPT_fseh_exceptions,
|
|
|
|
options::OPT_fdwarf_exceptions);
|
|
|
|
if (ExceptionArg &&
|
|
|
|
ExceptionArg->getOption().matches(options::OPT_fseh_exceptions))
|
|
|
|
return true;
|
2019-05-07 05:19:01 +08:00
|
|
|
return getArch() == llvm::Triple::x86_64 ||
|
|
|
|
getArch() == llvm::Triple::aarch64;
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool toolchains::MinGW::isPICDefault() const {
|
|
|
|
return getArch() == llvm::Triple::x86_64;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool toolchains::MinGW::isPIEDefault() const { return false; }
|
|
|
|
|
|
|
|
bool toolchains::MinGW::isPICDefaultForced() const {
|
|
|
|
return getArch() == llvm::Triple::x86_64;
|
|
|
|
}
|
|
|
|
|
2017-11-29 15:25:12 +08:00
|
|
|
llvm::ExceptionHandling
|
|
|
|
toolchains::MinGW::GetExceptionModel(const ArgList &Args) const {
|
2019-05-07 05:19:01 +08:00
|
|
|
if (getArch() == llvm::Triple::x86_64 || getArch() == llvm::Triple::aarch64)
|
2017-11-29 15:25:12 +08:00
|
|
|
return llvm::ExceptionHandling::WinEH;
|
|
|
|
return llvm::ExceptionHandling::DwarfCFI;
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
}
|
|
|
|
|
2018-10-02 04:53:25 +08:00
|
|
|
SanitizerMask toolchains::MinGW::getSupportedSanitizers() const {
|
|
|
|
SanitizerMask Res = ToolChain::getSupportedSanitizers();
|
|
|
|
Res |= SanitizerKind::Address;
|
2019-04-12 22:14:58 +08:00
|
|
|
Res |= SanitizerKind::PointerCompare;
|
|
|
|
Res |= SanitizerKind::PointerSubtract;
|
2018-10-02 04:53:25 +08:00
|
|
|
return Res;
|
|
|
|
}
|
|
|
|
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
void toolchains::MinGW::AddCudaIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
CudaInstallation.AddCudaIncludeArgs(DriverArgs, CC1Args);
|
|
|
|
}
|
|
|
|
|
|
|
|
void toolchains::MinGW::printVerboseInfo(raw_ostream &OS) const {
|
|
|
|
CudaInstallation.print(OS);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Include directories for various hosts:
|
|
|
|
|
|
|
|
// Windows, mingw.org
|
|
|
|
// c:\mingw\lib\gcc\mingw32\4.8.1\include\c++
|
|
|
|
// c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\mingw32
|
|
|
|
// c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\backward
|
|
|
|
// c:\mingw\include
|
|
|
|
// c:\mingw\mingw32\include
|
|
|
|
|
|
|
|
// Windows, mingw-w64 mingw-builds
|
|
|
|
// c:\mingw32\i686-w64-mingw32\include
|
|
|
|
// c:\mingw32\i686-w64-mingw32\include\c++
|
|
|
|
// c:\mingw32\i686-w64-mingw32\include\c++\i686-w64-mingw32
|
|
|
|
// c:\mingw32\i686-w64-mingw32\include\c++\backward
|
|
|
|
|
|
|
|
// Windows, mingw-w64 msys2
|
|
|
|
// c:\msys64\mingw32\include
|
|
|
|
// c:\msys64\mingw32\i686-w64-mingw32\include
|
|
|
|
// c:\msys64\mingw32\include\c++\4.9.2
|
|
|
|
// c:\msys64\mingw32\include\c++\4.9.2\i686-w64-mingw32
|
|
|
|
// c:\msys64\mingw32\include\c++\4.9.2\backward
|
|
|
|
|
|
|
|
// openSUSE
|
|
|
|
// /usr/lib64/gcc/x86_64-w64-mingw32/5.1.0/include/c++
|
|
|
|
// /usr/lib64/gcc/x86_64-w64-mingw32/5.1.0/include/c++/x86_64-w64-mingw32
|
|
|
|
// /usr/lib64/gcc/x86_64-w64-mingw32/5.1.0/include/c++/backward
|
|
|
|
// /usr/x86_64-w64-mingw32/sys-root/mingw/include
|
|
|
|
|
|
|
|
// Arch Linux
|
|
|
|
// /usr/i686-w64-mingw32/include/c++/5.1.0
|
|
|
|
// /usr/i686-w64-mingw32/include/c++/5.1.0/i686-w64-mingw32
|
|
|
|
// /usr/i686-w64-mingw32/include/c++/5.1.0/backward
|
|
|
|
// /usr/i686-w64-mingw32/include
|
|
|
|
|
|
|
|
// Ubuntu
|
|
|
|
// /usr/include/c++/4.8
|
|
|
|
// /usr/include/c++/4.8/x86_64-w64-mingw32
|
|
|
|
// /usr/include/c++/4.8/backward
|
|
|
|
// /usr/x86_64-w64-mingw32/include
|
|
|
|
|
|
|
|
void toolchains::MinGW::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdinc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!DriverArgs.hasArg(options::OPT_nobuiltininc)) {
|
|
|
|
SmallString<1024> P(getDriver().ResourceDir);
|
|
|
|
llvm::sys::path::append(P, "include");
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, P.str());
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdlibinc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (GetRuntimeLibType(DriverArgs) == ToolChain::RLT_Libgcc) {
|
|
|
|
// openSUSE
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
Base + Arch + "/sys-root/mingw/include");
|
|
|
|
}
|
|
|
|
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
Base + Arch + llvm::sys::path::get_separator() + "include");
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, Base + "include");
|
|
|
|
}
|
|
|
|
|
|
|
|
void toolchains::MinGW::AddClangCXXStdlibIncludeArgs(
|
|
|
|
const ArgList &DriverArgs, ArgStringList &CC1Args) const {
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
|
|
|
|
DriverArgs.hasArg(options::OPT_nostdincxx))
|
|
|
|
return;
|
|
|
|
|
2018-04-13 04:07:38 +08:00
|
|
|
StringRef Slash = llvm::sys::path::get_separator();
|
|
|
|
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
switch (GetCXXStdlibType(DriverArgs)) {
|
|
|
|
case ToolChain::CST_Libcxx:
|
2018-04-13 04:07:38 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, Base + Arch + Slash + "include" +
|
|
|
|
Slash + "c++" + Slash + "v1");
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
2018-04-13 04:07:38 +08:00
|
|
|
Base + "include" + Slash + "c++" + Slash + "v1");
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case ToolChain::CST_Libstdcxx:
|
|
|
|
llvm::SmallVector<llvm::SmallString<1024>, 4> CppIncludeBases;
|
|
|
|
CppIncludeBases.emplace_back(Base);
|
|
|
|
llvm::sys::path::append(CppIncludeBases[0], Arch, "include", "c++");
|
|
|
|
CppIncludeBases.emplace_back(Base);
|
|
|
|
llvm::sys::path::append(CppIncludeBases[1], Arch, "include", "c++", Ver);
|
|
|
|
CppIncludeBases.emplace_back(Base);
|
|
|
|
llvm::sys::path::append(CppIncludeBases[2], "include", "c++", Ver);
|
|
|
|
CppIncludeBases.emplace_back(GccLibDir);
|
|
|
|
llvm::sys::path::append(CppIncludeBases[3], "include", "c++");
|
|
|
|
for (auto &CppIncludeBase : CppIncludeBases) {
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, CppIncludeBase);
|
2018-04-13 04:07:38 +08:00
|
|
|
CppIncludeBase += Slash;
|
2017-10-12 07:54:34 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, CppIncludeBase + Arch);
|
[Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
2017-03-08 09:02:16 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, CppIncludeBase + "backward");
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|