[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
|
|
|
//===--- Solaris.cpp - Solaris ToolChain Implementations --------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "Solaris.h"
|
|
|
|
#include "CommonArgs.h"
|
|
|
|
#include "clang/Config/config.h"
|
|
|
|
#include "clang/Driver/Compilation.h"
|
|
|
|
#include "clang/Driver/Driver.h"
|
|
|
|
#include "clang/Driver/DriverDiagnostic.h"
|
|
|
|
#include "clang/Driver/Options.h"
|
|
|
|
#include "llvm/Option/ArgList.h"
|
|
|
|
#include "llvm/Support/FileSystem.h"
|
|
|
|
#include "llvm/Support/Path.h"
|
|
|
|
|
|
|
|
using namespace clang::driver;
|
|
|
|
using namespace clang::driver::tools;
|
|
|
|
using namespace clang::driver::toolchains;
|
|
|
|
using namespace clang;
|
|
|
|
using namespace llvm::opt;
|
|
|
|
|
|
|
|
void solaris::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const ArgList &Args,
|
|
|
|
const char *LinkingOutput) const {
|
|
|
|
claimNoWarnArgs(Args);
|
|
|
|
ArgStringList CmdArgs;
|
|
|
|
|
|
|
|
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"));
|
|
|
|
C.addCommand(llvm::make_unique<Command>(JA, *this, Exec, CmdArgs, Inputs));
|
|
|
|
}
|
|
|
|
|
|
|
|
void solaris::Linker::ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const ArgList &Args,
|
|
|
|
const char *LinkingOutput) const {
|
|
|
|
ArgStringList CmdArgs;
|
|
|
|
|
|
|
|
// Demangle C++ names in errors
|
|
|
|
CmdArgs.push_back("-C");
|
|
|
|
|
|
|
|
if (!Args.hasArg(options::OPT_nostdlib, options::OPT_shared)) {
|
|
|
|
CmdArgs.push_back("-e");
|
|
|
|
CmdArgs.push_back("_start");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Args.hasArg(options::OPT_static)) {
|
|
|
|
CmdArgs.push_back("-Bstatic");
|
|
|
|
CmdArgs.push_back("-dn");
|
|
|
|
} else {
|
|
|
|
CmdArgs.push_back("-Bdynamic");
|
|
|
|
if (Args.hasArg(options::OPT_shared)) {
|
|
|
|
CmdArgs.push_back("-shared");
|
|
|
|
} else {
|
|
|
|
CmdArgs.push_back("--dynamic-linker");
|
|
|
|
CmdArgs.push_back(
|
|
|
|
Args.MakeArgString(getToolChain().GetFilePath("ld.so.1")));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Output.isFilename()) {
|
|
|
|
CmdArgs.push_back("-o");
|
|
|
|
CmdArgs.push_back(Output.getFilename());
|
|
|
|
} else {
|
|
|
|
assert(Output.isNothing() && "Invalid output.");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {
|
|
|
|
if (!Args.hasArg(options::OPT_shared))
|
|
|
|
CmdArgs.push_back(
|
|
|
|
Args.MakeArgString(getToolChain().GetFilePath("crt1.o")));
|
|
|
|
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(getToolChain().GetFilePath("crti.o")));
|
|
|
|
CmdArgs.push_back(
|
|
|
|
Args.MakeArgString(getToolChain().GetFilePath("values-Xa.o")));
|
|
|
|
CmdArgs.push_back(
|
|
|
|
Args.MakeArgString(getToolChain().GetFilePath("crtbegin.o")));
|
|
|
|
}
|
|
|
|
|
|
|
|
getToolChain().AddFilePathLibArgs(Args, CmdArgs);
|
|
|
|
|
|
|
|
Args.AddAllArgs(CmdArgs, {options::OPT_L, options::OPT_T_Group,
|
|
|
|
options::OPT_e, options::OPT_r});
|
|
|
|
|
|
|
|
AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
|
|
|
|
|
|
|
|
if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
|
2017-07-26 02:02:57 +08:00
|
|
|
if (getToolChain().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
|
|
|
getToolChain().AddCXXStdlibLibArgs(Args, CmdArgs);
|
|
|
|
CmdArgs.push_back("-lgcc_s");
|
|
|
|
CmdArgs.push_back("-lc");
|
|
|
|
if (!Args.hasArg(options::OPT_shared)) {
|
|
|
|
CmdArgs.push_back("-lgcc");
|
|
|
|
CmdArgs.push_back("-lm");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {
|
|
|
|
CmdArgs.push_back(
|
|
|
|
Args.MakeArgString(getToolChain().GetFilePath("crtend.o")));
|
|
|
|
}
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(getToolChain().GetFilePath("crtn.o")));
|
|
|
|
|
|
|
|
getToolChain().addProfileRTLibs(Args, CmdArgs);
|
|
|
|
|
|
|
|
const char *Exec = Args.MakeArgString(getToolChain().GetLinkerPath());
|
|
|
|
C.addCommand(llvm::make_unique<Command>(JA, *this, Exec, CmdArgs, Inputs));
|
|
|
|
}
|
|
|
|
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
static StringRef getSolarisLibSuffix(const llvm::Triple &Triple) {
|
|
|
|
switch (Triple.getArch()) {
|
|
|
|
case llvm::Triple::x86:
|
|
|
|
case llvm::Triple::sparc:
|
|
|
|
break;
|
|
|
|
case llvm::Triple::x86_64:
|
|
|
|
return "/amd64";
|
|
|
|
case llvm::Triple::sparcv9:
|
|
|
|
return "/sparcv9";
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unsupported architecture");
|
|
|
|
}
|
|
|
|
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
|
|
|
/// Solaris - Solaris tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
|
|
|
Solaris::Solaris(const Driver &D, const llvm::Triple &Triple,
|
|
|
|
const ArgList &Args)
|
2017-07-15 01:49:52 +08:00
|
|
|
: Generic_ELF(D, Triple, 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
|
|
|
|
|
|
|
GCCInstallation.init(Triple, Args);
|
|
|
|
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
StringRef LibSuffix = getSolarisLibSuffix(Triple);
|
[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
|
|
|
path_list &Paths = getFilePaths();
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
if (GCCInstallation.isValid()) {
|
|
|
|
// On Solaris gcc uses both an architecture-specific path with triple in it
|
|
|
|
// as well as a more generic lib path (+arch suffix).
|
|
|
|
addPathIfExists(D,
|
|
|
|
GCCInstallation.getInstallPath() +
|
|
|
|
GCCInstallation.getMultilib().gccSuffix(),
|
|
|
|
Paths);
|
|
|
|
addPathIfExists(D, GCCInstallation.getParentLibPath() + LibSuffix, Paths);
|
[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
|
|
|
}
|
|
|
|
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
// If we are currently running Clang inside of the requested system root,
|
|
|
|
// add its parent library path to those searched.
|
|
|
|
if (StringRef(D.Dir).startswith(D.SysRoot))
|
|
|
|
addPathIfExists(D, D.Dir + "/../lib", Paths);
|
|
|
|
|
|
|
|
addPathIfExists(D, D.SysRoot + "/usr/lib" + LibSuffix, Paths);
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Solaris::buildAssembler() const {
|
|
|
|
return new tools::solaris::Assembler(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Solaris::buildLinker() const { return new tools::solaris::Linker(*this); }
|
|
|
|
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
void Solaris::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
const Driver &D = getDriver();
|
|
|
|
|
|
|
|
if (DriverArgs.hasArg(clang::driver::options::OPT_nostdinc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!DriverArgs.hasArg(options::OPT_nostdlibinc))
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, D.SysRoot + "/usr/local/include");
|
|
|
|
|
|
|
|
if (!DriverArgs.hasArg(options::OPT_nobuiltininc)) {
|
|
|
|
SmallString<128> P(D.ResourceDir);
|
|
|
|
llvm::sys::path::append(P, "include");
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, P);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdlibinc))
|
[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;
|
|
|
|
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
// Check for configure-time C include directories.
|
|
|
|
StringRef CIncludeDirs(C_INCLUDE_DIRS);
|
|
|
|
if (CIncludeDirs != "") {
|
|
|
|
SmallVector<StringRef, 5> dirs;
|
|
|
|
CIncludeDirs.split(dirs, ":");
|
|
|
|
for (StringRef dir : dirs) {
|
|
|
|
StringRef Prefix =
|
|
|
|
llvm::sys::path::is_absolute(dir) ? StringRef(D.SysRoot) : "";
|
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, Prefix + dir);
|
|
|
|
}
|
|
|
|
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
|
|
|
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
// Add include directories specific to the selected multilib set and multilib.
|
[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 (GCCInstallation.isValid()) {
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
const MultilibSet::IncludeDirsFunc &Callback =
|
|
|
|
Multilibs.includeDirsCallback();
|
|
|
|
if (Callback) {
|
|
|
|
for (const auto &Path : Callback(GCCInstallation.getMultilib()))
|
|
|
|
addExternCSystemIncludeIfExists(
|
|
|
|
DriverArgs, CC1Args, GCCInstallation.getInstallPath() + Path);
|
|
|
|
}
|
[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
|
|
|
}
|
[Solaris] gcc toolchain handling revamp
Summary:
General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.
In particular:
- scanLibDirForGCCTripleSolaris was removed, relying on generic
CollectLibDirsAndTriples
- findBiarchMultilibs is now properly utilized to switch between
m32 and m64 include & lib paths on Solaris
- C system include handling copied from Linux (bar multilib hacks)
Fixes PR24606.
Reviewers: dlj, rafael, jyknight, theraven, tstellar
Reviewed By: jyknight
Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35755
llvm-svn: 323193
2018-01-23 20:23:52 +08:00
|
|
|
|
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, D.SysRoot + "/usr/include");
|
|
|
|
}
|
|
|
|
|
|
|
|
void Solaris::addLibStdCxxIncludePaths(
|
|
|
|
const llvm::opt::ArgList &DriverArgs,
|
|
|
|
llvm::opt::ArgStringList &CC1Args) const {
|
|
|
|
// We need a detected GCC installation on Solaris (similar to Linux)
|
|
|
|
// to provide libstdc++'s headers.
|
|
|
|
if (!GCCInstallation.isValid())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// By default, look for the C++ headers in an include directory adjacent to
|
|
|
|
// the lib directory of the GCC installation.
|
|
|
|
// On Solaris this usually looks like /usr/gcc/X.Y/include/c++/X.Y.Z
|
|
|
|
StringRef LibDir = GCCInstallation.getParentLibPath();
|
|
|
|
StringRef TripleStr = GCCInstallation.getTriple().str();
|
|
|
|
const Multilib &Multilib = GCCInstallation.getMultilib();
|
|
|
|
const GCCVersion &Version = GCCInstallation.getVersion();
|
|
|
|
|
|
|
|
// The primary search for libstdc++ supports multiarch variants.
|
|
|
|
addLibStdCXXIncludePaths(LibDir.str() + "/../include", "/c++/" + Version.Text,
|
|
|
|
TripleStr,
|
|
|
|
/*GCCMultiarchTriple*/ "",
|
|
|
|
/*TargetMultiarchTriple*/ "",
|
|
|
|
Multilib.includeSuffix(), DriverArgs, CC1Args);
|
[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
|
|
|
}
|