2018-03-21 05:08:59 +08:00
|
|
|
//===- ToolChain.cpp - Collections of tools for one platform --------------===//
|
2009-03-16 13:25:36 +08:00
|
|
|
//
|
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
|
2009-03-16 13:25:36 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-07-19 03:02:11 +08:00
|
|
|
#include "clang/Driver/ToolChain.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "InputInfo.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 "ToolChains/Arch/ARM.h"
|
|
|
|
#include "ToolChains/Clang.h"
|
2019-10-08 23:23:14 +08:00
|
|
|
#include "ToolChains/InterfaceStubs.h"
|
2019-06-10 21:12:43 +08:00
|
|
|
#include "ToolChains/Flang.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/Basic/ObjCRuntime.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "clang/Basic/Sanitizers.h"
|
2016-02-12 15:48:37 +08:00
|
|
|
#include "clang/Config/config.h"
|
2009-03-16 13:25:36 +08:00
|
|
|
#include "clang/Driver/Action.h"
|
|
|
|
#include "clang/Driver/Driver.h"
|
2010-08-24 06:35:37 +08:00
|
|
|
#include "clang/Driver/DriverDiagnostic.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "clang/Driver/Job.h"
|
2010-08-24 06:35:37 +08:00
|
|
|
#include "clang/Driver/Options.h"
|
2013-11-02 02:16:25 +08:00
|
|
|
#include "clang/Driver/SanitizerArgs.h"
|
2017-03-30 08:29:36 +08:00
|
|
|
#include "clang/Driver/XRayArgs.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2014-06-26 22:23:45 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/ADT/Triple.h"
|
|
|
|
#include "llvm/ADT/Twine.h"
|
|
|
|
#include "llvm/Config/llvm-config.h"
|
2018-06-11 18:28:04 +08:00
|
|
|
#include "llvm/MC/MCTargetOptions.h"
|
2013-06-15 01:17:23 +08:00
|
|
|
#include "llvm/Option/Arg.h"
|
|
|
|
#include "llvm/Option/ArgList.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include "llvm/Option/OptTable.h"
|
2013-06-15 01:17:23 +08:00
|
|
|
#include "llvm/Option/Option.h"
|
2011-07-06 08:26:06 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2013-04-20 16:15:03 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2016-07-19 03:02:11 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2015-10-28 18:10:03 +08:00
|
|
|
#include "llvm/Support/TargetParser.h"
|
2016-07-19 03:02:11 +08:00
|
|
|
#include "llvm/Support/TargetRegistry.h"
|
2018-06-11 18:28:04 +08:00
|
|
|
#include "llvm/Support/VersionTuple.h"
|
2018-10-10 21:27:25 +08:00
|
|
|
#include "llvm/Support/VirtualFileSystem.h"
|
2018-03-21 05:08:59 +08:00
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
|
|
|
#include <cstring>
|
|
|
|
#include <string>
|
2015-10-02 00:54:58 +08:00
|
|
|
|
2011-07-23 18:55:15 +08:00
|
|
|
using namespace clang;
|
2018-03-21 05:08:59 +08:00
|
|
|
using namespace driver;
|
|
|
|
using namespace tools;
|
2015-10-28 18:10:03 +08:00
|
|
|
using namespace llvm;
|
2013-06-15 01:17:23 +08:00
|
|
|
using namespace llvm::opt;
|
2009-03-16 13:25:36 +08:00
|
|
|
|
Improve our handling of rtti/sanitize=vptr/sanitize=undefined
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
2015-02-19 09:04:49 +08:00
|
|
|
static llvm::opt::Arg *GetRTTIArgument(const ArgList &Args) {
|
|
|
|
return Args.getLastArg(options::OPT_mkernel, options::OPT_fapple_kext,
|
|
|
|
options::OPT_fno_rtti, options::OPT_frtti);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ToolChain::RTTIMode CalculateRTTIMode(const ArgList &Args,
|
|
|
|
const llvm::Triple &Triple,
|
|
|
|
const Arg *CachedRTTIArg) {
|
|
|
|
// Explicit rtti/no-rtti args
|
|
|
|
if (CachedRTTIArg) {
|
|
|
|
if (CachedRTTIArg->getOption().matches(options::OPT_frtti))
|
2018-05-19 07:32:01 +08:00
|
|
|
return ToolChain::RM_Enabled;
|
Improve our handling of rtti/sanitize=vptr/sanitize=undefined
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
2015-02-19 09:04:49 +08:00
|
|
|
else
|
2018-05-19 07:32:01 +08:00
|
|
|
return ToolChain::RM_Disabled;
|
Improve our handling of rtti/sanitize=vptr/sanitize=undefined
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
2015-02-19 09:04:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// -frtti is default, except for the PS4 CPU.
|
2020-01-16 06:41:15 +08:00
|
|
|
return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled : ToolChain::RM_Enabled;
|
Improve our handling of rtti/sanitize=vptr/sanitize=undefined
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
2015-02-19 09:04:49 +08:00
|
|
|
}
|
|
|
|
|
2013-03-19 02:10:27 +08:00
|
|
|
ToolChain::ToolChain(const Driver &D, const llvm::Triple &T,
|
2014-10-04 05:57:44 +08:00
|
|
|
const ArgList &Args)
|
Improve our handling of rtti/sanitize=vptr/sanitize=undefined
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
2015-02-19 09:04:49 +08:00
|
|
|
: D(D), Triple(T), Args(Args), CachedRTTIArg(GetRTTIArgument(Args)),
|
2018-03-21 05:08:59 +08:00
|
|
|
CachedRTTIMode(CalculateRTTIMode(Args, Triple, CachedRTTIArg)) {
|
2021-04-28 13:31:36 +08:00
|
|
|
std::string RuntimePath = getRuntimePath();
|
|
|
|
if (getVFS().exists(RuntimePath))
|
|
|
|
getLibraryPaths().push_back(RuntimePath);
|
|
|
|
|
|
|
|
std::string StdlibPath = getStdlibPath();
|
|
|
|
if (getVFS().exists(StdlibPath))
|
|
|
|
getFilePaths().push_back(StdlibPath);
|
|
|
|
|
2017-03-04 07:20:49 +08:00
|
|
|
std::string CandidateLibPath = getArchSpecificLibPath();
|
|
|
|
if (getVFS().exists(CandidateLibPath))
|
|
|
|
getFilePaths().push_back(CandidateLibPath);
|
2009-03-16 13:25:36 +08:00
|
|
|
}
|
|
|
|
|
2017-12-08 03:04:10 +08:00
|
|
|
void ToolChain::setTripleEnvironment(llvm::Triple::EnvironmentType Env) {
|
|
|
|
Triple.setEnvironment(Env);
|
|
|
|
if (EffectiveTriple != llvm::Triple())
|
|
|
|
EffectiveTriple.setEnvironment(Env);
|
|
|
|
}
|
|
|
|
|
2018-03-21 05:08:59 +08:00
|
|
|
ToolChain::~ToolChain() = default;
|
2009-03-16 13:25:36 +08:00
|
|
|
|
2018-10-10 21:27:25 +08:00
|
|
|
llvm::vfs::FileSystem &ToolChain::getVFS() const {
|
|
|
|
return getDriver().getVFS();
|
|
|
|
}
|
2009-12-22 02:54:17 +08:00
|
|
|
|
2013-03-19 02:10:27 +08:00
|
|
|
bool ToolChain::useIntegratedAs() const {
|
2014-02-23 08:40:30 +08:00
|
|
|
return Args.hasFlag(options::OPT_fintegrated_as,
|
|
|
|
options::OPT_fno_integrated_as,
|
2013-03-19 01:52:57 +08:00
|
|
|
IsIntegratedAssemblerDefault());
|
|
|
|
}
|
|
|
|
|
2017-11-22 09:38:31 +08:00
|
|
|
bool ToolChain::useRelaxRelocations() const {
|
|
|
|
return ENABLE_X86_RELAX_RELOCATIONS;
|
|
|
|
}
|
|
|
|
|
2019-03-29 02:08:28 +08:00
|
|
|
bool ToolChain::isNoExecStackDefault() const {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-08-19 17:14:21 +08:00
|
|
|
const SanitizerArgs& ToolChain::getSanitizerArgs() const {
|
2013-11-02 02:16:25 +08:00
|
|
|
if (!SanitizerArguments.get())
|
|
|
|
SanitizerArguments.reset(new SanitizerArgs(*this, Args));
|
|
|
|
return *SanitizerArguments.get();
|
2013-08-19 17:14:21 +08:00
|
|
|
}
|
|
|
|
|
2017-03-30 08:29:36 +08:00
|
|
|
const XRayArgs& ToolChain::getXRayArgs() const {
|
|
|
|
if (!XRayArguments.get())
|
|
|
|
XRayArguments.reset(new XRayArgs(*this, Args));
|
|
|
|
return *XRayArguments.get();
|
|
|
|
}
|
|
|
|
|
2015-09-26 01:44:31 +08:00
|
|
|
namespace {
|
2018-03-21 05:08:59 +08:00
|
|
|
|
2015-09-26 01:44:31 +08:00
|
|
|
struct DriverSuffix {
|
|
|
|
const char *Suffix;
|
|
|
|
const char *ModeFlag;
|
|
|
|
};
|
|
|
|
|
2018-03-21 05:08:59 +08:00
|
|
|
} // namespace
|
|
|
|
|
|
|
|
static const DriverSuffix *FindDriverSuffix(StringRef ProgName, size_t &Pos) {
|
2015-09-26 01:44:31 +08:00
|
|
|
// A list of known driver suffixes. Suffixes are compared against the
|
|
|
|
// program name in order. If there is a match, the frontend type is updated as
|
|
|
|
// necessary by applying the ModeFlag.
|
|
|
|
static const DriverSuffix DriverSuffixes[] = {
|
|
|
|
{"clang", nullptr},
|
|
|
|
{"clang++", "--driver-mode=g++"},
|
|
|
|
{"clang-c++", "--driver-mode=g++"},
|
|
|
|
{"clang-cc", nullptr},
|
|
|
|
{"clang-cpp", "--driver-mode=cpp"},
|
|
|
|
{"clang-g++", "--driver-mode=g++"},
|
|
|
|
{"clang-gcc", nullptr},
|
|
|
|
{"clang-cl", "--driver-mode=cl"},
|
|
|
|
{"cc", nullptr},
|
|
|
|
{"cpp", "--driver-mode=cpp"},
|
|
|
|
{"cl", "--driver-mode=cl"},
|
|
|
|
{"++", "--driver-mode=g++"},
|
2019-06-10 21:12:43 +08:00
|
|
|
{"flang", "--driver-mode=flang"},
|
2015-09-26 01:44:31 +08:00
|
|
|
};
|
|
|
|
|
2017-08-29 13:22:26 +08:00
|
|
|
for (size_t i = 0; i < llvm::array_lengthof(DriverSuffixes); ++i) {
|
|
|
|
StringRef Suffix(DriverSuffixes[i].Suffix);
|
|
|
|
if (ProgName.endswith(Suffix)) {
|
|
|
|
Pos = ProgName.size() - Suffix.size();
|
2015-09-26 01:44:31 +08:00
|
|
|
return &DriverSuffixes[i];
|
2017-08-29 13:22:26 +08:00
|
|
|
}
|
|
|
|
}
|
2015-09-26 01:44:31 +08:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Normalize the program name from argv[0] by stripping the file extension if
|
|
|
|
/// present and lower-casing the string on Windows.
|
2018-03-21 05:08:59 +08:00
|
|
|
static std::string normalizeProgramName(llvm::StringRef Argv0) {
|
2020-01-29 03:23:46 +08:00
|
|
|
std::string ProgName = std::string(llvm::sys::path::stem(Argv0));
|
2018-04-28 03:11:14 +08:00
|
|
|
#ifdef _WIN32
|
2015-09-26 01:44:31 +08:00
|
|
|
// Transform to lowercase for case insensitive file systems.
|
|
|
|
std::transform(ProgName.begin(), ProgName.end(), ProgName.begin(), ::tolower);
|
|
|
|
#endif
|
|
|
|
return ProgName;
|
|
|
|
}
|
|
|
|
|
2018-03-21 05:08:59 +08:00
|
|
|
static const DriverSuffix *parseDriverSuffix(StringRef ProgName, size_t &Pos) {
|
2015-09-26 01:44:31 +08:00
|
|
|
// Try to infer frontend type and default target from the program name by
|
|
|
|
// comparing it against DriverSuffixes in order.
|
|
|
|
|
|
|
|
// If there is a match, the function tries to identify a target as prefix.
|
|
|
|
// E.g. "x86_64-linux-clang" as interpreted as suffix "clang" with target
|
|
|
|
// prefix "x86_64-linux". If such a target prefix is found, it may be
|
|
|
|
// added via -target as implicit first argument.
|
2017-08-29 13:22:26 +08:00
|
|
|
const DriverSuffix *DS = FindDriverSuffix(ProgName, Pos);
|
2015-09-26 01:44:31 +08:00
|
|
|
|
|
|
|
if (!DS) {
|
|
|
|
// Try again after stripping any trailing version number:
|
|
|
|
// clang++3.5 -> clang++
|
|
|
|
ProgName = ProgName.rtrim("0123456789.");
|
2017-08-29 13:22:26 +08:00
|
|
|
DS = FindDriverSuffix(ProgName, Pos);
|
2015-09-26 01:44:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!DS) {
|
|
|
|
// Try again after stripping trailing -component.
|
|
|
|
// clang++-tot -> clang++
|
|
|
|
ProgName = ProgName.slice(0, ProgName.rfind('-'));
|
2017-08-29 13:22:26 +08:00
|
|
|
DS = FindDriverSuffix(ProgName, Pos);
|
2015-09-26 01:44:31 +08:00
|
|
|
}
|
|
|
|
return DS;
|
|
|
|
}
|
|
|
|
|
2017-08-29 13:22:26 +08:00
|
|
|
ParsedClangName
|
2015-09-26 01:44:31 +08:00
|
|
|
ToolChain::getTargetAndModeFromProgramName(StringRef PN) {
|
|
|
|
std::string ProgName = normalizeProgramName(PN);
|
2017-08-29 13:22:26 +08:00
|
|
|
size_t SuffixPos;
|
|
|
|
const DriverSuffix *DS = parseDriverSuffix(ProgName, SuffixPos);
|
2015-09-26 01:44:31 +08:00
|
|
|
if (!DS)
|
2018-03-21 05:08:59 +08:00
|
|
|
return {};
|
2017-08-29 13:22:26 +08:00
|
|
|
size_t SuffixEnd = SuffixPos + strlen(DS->Suffix);
|
2015-09-26 01:44:31 +08:00
|
|
|
|
2017-08-29 13:22:26 +08:00
|
|
|
size_t LastComponent = ProgName.rfind('-', SuffixPos);
|
2015-09-26 01:44:31 +08:00
|
|
|
if (LastComponent == std::string::npos)
|
2017-08-29 13:22:26 +08:00
|
|
|
return ParsedClangName(ProgName.substr(0, SuffixEnd), DS->ModeFlag);
|
|
|
|
std::string ModeSuffix = ProgName.substr(LastComponent + 1,
|
|
|
|
SuffixEnd - LastComponent - 1);
|
2015-09-26 01:44:31 +08:00
|
|
|
|
|
|
|
// Infer target from the prefix.
|
|
|
|
StringRef Prefix(ProgName);
|
|
|
|
Prefix = Prefix.slice(0, LastComponent);
|
|
|
|
std::string IgnoredError;
|
2020-01-29 03:23:46 +08:00
|
|
|
bool IsRegistered =
|
|
|
|
llvm::TargetRegistry::lookupTarget(std::string(Prefix), IgnoredError);
|
|
|
|
return ParsedClangName{std::string(Prefix), ModeSuffix, DS->ModeFlag,
|
|
|
|
IsRegistered};
|
2015-09-26 01:44:31 +08:00
|
|
|
}
|
|
|
|
|
2014-07-26 03:22:51 +08:00
|
|
|
StringRef ToolChain::getDefaultUniversalArchName() const {
|
2012-11-08 11:38:26 +08:00
|
|
|
// In universal driver terms, the arch name accepted by -arch isn't exactly
|
|
|
|
// the same as the ones that appear in the triple. Roughly speaking, this is
|
2020-04-30 03:19:48 +08:00
|
|
|
// an inverse of the darwin::getArchTypeForDarwinArchName() function.
|
2012-11-08 11:38:26 +08:00
|
|
|
switch (Triple.getArch()) {
|
2020-09-03 23:43:21 +08:00
|
|
|
case llvm::Triple::aarch64: {
|
|
|
|
if (getTriple().isArm64e())
|
|
|
|
return "arm64e";
|
2020-04-30 03:19:48 +08:00
|
|
|
return "arm64";
|
2020-09-03 23:43:21 +08:00
|
|
|
}
|
2020-04-30 03:19:48 +08:00
|
|
|
case llvm::Triple::aarch64_32:
|
|
|
|
return "arm64_32";
|
2012-11-08 11:38:26 +08:00
|
|
|
case llvm::Triple::ppc:
|
|
|
|
return "ppc";
|
2021-01-03 02:17:58 +08:00
|
|
|
case llvm::Triple::ppcle:
|
|
|
|
return "ppcle";
|
2012-11-08 11:38:26 +08:00
|
|
|
case llvm::Triple::ppc64:
|
|
|
|
return "ppc64";
|
2013-07-26 09:36:11 +08:00
|
|
|
case llvm::Triple::ppc64le:
|
|
|
|
return "ppc64le";
|
2012-11-08 11:38:26 +08:00
|
|
|
default:
|
|
|
|
return Triple.getArchName();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-21 22:44:45 +08:00
|
|
|
std::string ToolChain::getInputFilename(const InputInfo &Input) const {
|
|
|
|
return Input.getFilename();
|
|
|
|
}
|
|
|
|
|
2017-08-04 07:55:42 +08:00
|
|
|
bool ToolChain::IsUnwindTablesDefault(const ArgList &Args) const {
|
2012-09-23 11:05:41 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *ToolChain::getClang() const {
|
|
|
|
if (!Clang)
|
|
|
|
Clang.reset(new tools::Clang(*this));
|
|
|
|
return Clang.get();
|
|
|
|
}
|
|
|
|
|
2019-06-10 21:12:43 +08:00
|
|
|
Tool *ToolChain::getFlang() const {
|
|
|
|
if (!Flang)
|
|
|
|
Flang.reset(new tools::Flang(*this));
|
|
|
|
return Flang.get();
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *ToolChain::buildAssembler() const {
|
|
|
|
return new tools::ClangAs(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *ToolChain::buildLinker() const {
|
|
|
|
llvm_unreachable("Linking is not supported by this toolchain");
|
|
|
|
}
|
|
|
|
|
2020-05-28 02:49:25 +08:00
|
|
|
Tool *ToolChain::buildStaticLibTool() const {
|
|
|
|
llvm_unreachable("Creating static lib is not supported by this toolchain");
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *ToolChain::getAssemble() const {
|
|
|
|
if (!Assemble)
|
|
|
|
Assemble.reset(buildAssembler());
|
|
|
|
return Assemble.get();
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *ToolChain::getClangAs() const {
|
|
|
|
if (!Assemble)
|
|
|
|
Assemble.reset(new tools::ClangAs(*this));
|
|
|
|
return Assemble.get();
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *ToolChain::getLink() const {
|
|
|
|
if (!Link)
|
|
|
|
Link.reset(buildLinker());
|
|
|
|
return Link.get();
|
|
|
|
}
|
|
|
|
|
2020-05-28 02:49:25 +08:00
|
|
|
Tool *ToolChain::getStaticLibTool() const {
|
|
|
|
if (!StaticLibTool)
|
|
|
|
StaticLibTool.reset(buildStaticLibTool());
|
|
|
|
return StaticLibTool.get();
|
|
|
|
}
|
|
|
|
|
2019-10-08 23:23:14 +08:00
|
|
|
Tool *ToolChain::getIfsMerge() const {
|
|
|
|
if (!IfsMerge)
|
|
|
|
IfsMerge.reset(new tools::ifstool::Merger(*this));
|
|
|
|
return IfsMerge.get();
|
|
|
|
}
|
|
|
|
|
[Driver][OpenMP] Add support to create jobs for bundling actions.
Summary: This patch adds the support to create a job for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21856
llvm-svn: 285325
2016-10-28 02:04:42 +08:00
|
|
|
Tool *ToolChain::getOffloadBundler() const {
|
|
|
|
if (!OffloadBundler)
|
|
|
|
OffloadBundler.reset(new tools::OffloadBundler(*this));
|
|
|
|
return OffloadBundler.get();
|
|
|
|
}
|
|
|
|
|
2019-10-10 04:42:58 +08:00
|
|
|
Tool *ToolChain::getOffloadWrapper() const {
|
|
|
|
if (!OffloadWrapper)
|
|
|
|
OffloadWrapper.reset(new tools::OffloadWrapper(*this));
|
|
|
|
return OffloadWrapper.get();
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *ToolChain::getTool(Action::ActionClass AC) const {
|
2013-03-19 08:36:57 +08:00
|
|
|
switch (AC) {
|
|
|
|
case Action::AssembleJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
return getAssemble();
|
|
|
|
|
2019-10-08 23:23:14 +08:00
|
|
|
case Action::IfsMergeJobClass:
|
|
|
|
return getIfsMerge();
|
|
|
|
|
2013-03-19 08:36:57 +08:00
|
|
|
case Action::LinkJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
return getLink();
|
|
|
|
|
2020-05-28 02:49:25 +08:00
|
|
|
case Action::StaticLibJobClass:
|
|
|
|
return getStaticLibTool();
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
case Action::InputClass:
|
|
|
|
case Action::BindArchClass:
|
[CUDA][OpenMP] Create generic offload action
Summary:
This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs.
This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture.
This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures)
```
0: input, "cudatests.cu", cuda, (host-cuda)
1: preprocessor, {0}, cuda-cpp-output, (host-cuda)
2: compiler, {1}, ir, (host-cuda)
3: input, "cudatests.cu", cuda, (device-cuda, sm_35)
4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35)
5: compiler, {4}, ir, (device-cuda, sm_35)
6: backend, {5}, assembler, (device-cuda, sm_35)
7: assembler, {6}, object, (device-cuda, sm_35)
8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object
9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler
10: input, "cudatests.cu", cuda, (device-cuda, sm_37)
11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37)
12: compiler, {11}, ir, (device-cuda, sm_37)
13: backend, {12}, assembler, (device-cuda, sm_37)
14: assembler, {13}, object, (device-cuda, sm_37)
15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object
16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler
17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda)
18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir
19: backend, {18}, assembler
20: assembler, {19}, object
21: input, "cuda", object
22: input, "cudart", object
23: linker, {20, 21, 22}, image
```
The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine.
Reviewers: echristo, hfinkel, jlebar, ABataev, tra
Subscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D18171
llvm-svn: 275645
2016-07-16 07:13:27 +08:00
|
|
|
case Action::OffloadClass:
|
2013-03-19 08:36:57 +08:00
|
|
|
case Action::LipoJobClass:
|
|
|
|
case Action::DsymutilJobClass:
|
2014-02-07 02:53:25 +08:00
|
|
|
case Action::VerifyDebugInfoJobClass:
|
2013-03-19 08:36:57 +08:00
|
|
|
llvm_unreachable("Invalid tool kind.");
|
|
|
|
|
|
|
|
case Action::CompileJobClass:
|
|
|
|
case Action::PrecompileJobClass:
|
2018-09-15 09:21:16 +08:00
|
|
|
case Action::HeaderModulePrecompileJobClass:
|
2013-03-19 08:36:57 +08:00
|
|
|
case Action::PreprocessJobClass:
|
|
|
|
case Action::AnalyzeJobClass:
|
|
|
|
case Action::MigrateJobClass:
|
2014-02-07 02:53:25 +08:00
|
|
|
case Action::VerifyPCHJobClass:
|
Reapply "Change -save-temps to emit unoptimized bitcode files."
This reapplies r224503 along with a fix for compiling Fortran by having the
clang driver invoke gcc (see r224546, where it was reverted). I have added
a testcase for that as well.
Original commit message:
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
llvm-svn: 224688
2014-12-21 15:00:00 +08:00
|
|
|
case Action::BackendJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
return getClang();
|
[Driver][OpenMP] Update actions builder to create bundling action when necessary.
Summary:
In order to save the user from dealing with multiple output files (for host and device) while using separate compilation, a new action `OffloadBundlingAction` is used when the last phase is not linking. This action will then result in a job that uses the proposed bundling tool to create a single preprocessed/IR/ASM/Object file from multiple ones.
The job creation for the new action will be proposed in a separate patch.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21852
llvm-svn: 285323
2016-10-28 01:50:43 +08:00
|
|
|
|
|
|
|
case Action::OffloadBundlingJobClass:
|
[Driver][OpenMP] Update actions builder to create unbundling action when necessary.
Summary:
Each time that offloading support is requested by the user and the input file is not a source file, an action `OffloadUnbundlingAction` is created to signal that the input file may contain bundles, so that the proper tool is then invoked to attempt to extract the components of the bundle. This patch adds the logic to create that action in offload action builder.
The job creation for the new action will be proposed in a separate patch.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21853
llvm-svn: 285324
2016-10-28 02:00:51 +08:00
|
|
|
case Action::OffloadUnbundlingJobClass:
|
[Driver][OpenMP] Add support to create jobs for bundling actions.
Summary: This patch adds the support to create a job for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21856
llvm-svn: 285325
2016-10-28 02:04:42 +08:00
|
|
|
return getOffloadBundler();
|
2019-10-10 04:42:58 +08:00
|
|
|
|
|
|
|
case Action::OffloadWrapperJobClass:
|
|
|
|
return getOffloadWrapper();
|
2013-03-19 08:36:57 +08:00
|
|
|
}
|
2013-03-22 03:45:46 +08:00
|
|
|
|
|
|
|
llvm_unreachable("Invalid tool kind.");
|
2013-03-19 08:36:57 +08:00
|
|
|
}
|
|
|
|
|
2016-07-28 07:01:55 +08:00
|
|
|
static StringRef getArchNameForCompilerRTLib(const ToolChain &TC,
|
|
|
|
const ArgList &Args) {
|
|
|
|
const llvm::Triple &Triple = TC.getTriple();
|
|
|
|
bool IsWindows = Triple.isOSWindows();
|
|
|
|
|
2015-10-02 00:54:58 +08:00
|
|
|
if (TC.getArch() == llvm::Triple::arm || TC.getArch() == llvm::Triple::armeb)
|
2016-07-28 07:01:55 +08:00
|
|
|
return (arm::getARMFloatABI(TC, Args) == arm::FloatABI::Hard && !IsWindows)
|
2015-10-02 00:54:58 +08:00
|
|
|
? "armhf"
|
|
|
|
: "arm";
|
|
|
|
|
2017-08-30 06:12:31 +08:00
|
|
|
// For historic reasons, Android library is using i686 instead of i386.
|
|
|
|
if (TC.getArch() == llvm::Triple::x86 && Triple.isAndroid())
|
|
|
|
return "i686";
|
|
|
|
|
2017-08-29 04:29:52 +08:00
|
|
|
return llvm::Triple::getArchTypeName(TC.getArch());
|
2015-10-02 00:54:58 +08:00
|
|
|
}
|
|
|
|
|
[Sanitizers] Basic Solaris sanitizer support (PR 33274)
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
2018-02-06 07:59:13 +08:00
|
|
|
StringRef ToolChain::getOSLibName() const {
|
2021-05-01 10:10:18 +08:00
|
|
|
if (Triple.isOSDarwin())
|
|
|
|
return "darwin";
|
|
|
|
|
[Sanitizers] Basic Solaris sanitizer support (PR 33274)
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
2018-02-06 07:59:13 +08:00
|
|
|
switch (Triple.getOS()) {
|
|
|
|
case llvm::Triple::FreeBSD:
|
|
|
|
return "freebsd";
|
2018-02-28 02:16:47 +08:00
|
|
|
case llvm::Triple::NetBSD:
|
|
|
|
return "netbsd";
|
2018-03-03 19:47:27 +08:00
|
|
|
case llvm::Triple::OpenBSD:
|
|
|
|
return "openbsd";
|
[Sanitizers] Basic Solaris sanitizer support (PR 33274)
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
2018-02-06 07:59:13 +08:00
|
|
|
case llvm::Triple::Solaris:
|
|
|
|
return "sunos";
|
2020-09-04 06:34:57 +08:00
|
|
|
case llvm::Triple::AIX:
|
|
|
|
return "aix";
|
[Sanitizers] Basic Solaris sanitizer support (PR 33274)
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
2018-02-06 07:59:13 +08:00
|
|
|
default:
|
|
|
|
return getOS();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-10 12:16:38 +08:00
|
|
|
std::string ToolChain::getCompilerRTPath() const {
|
|
|
|
SmallString<128> Path(getDriver().ResourceDir);
|
2017-10-28 02:10:19 +08:00
|
|
|
if (Triple.isOSUnknown()) {
|
|
|
|
llvm::sys::path::append(Path, "lib");
|
|
|
|
} else {
|
[Sanitizers] Basic Solaris sanitizer support (PR 33274)
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
2018-02-06 07:59:13 +08:00
|
|
|
llvm::sys::path::append(Path, "lib", getOSLibName());
|
2017-10-28 02:10:19 +08:00
|
|
|
}
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(Path.str());
|
2017-08-10 12:16:38 +08:00
|
|
|
}
|
|
|
|
|
2021-02-24 09:38:16 +08:00
|
|
|
std::string ToolChain::getCompilerRTBasename(const ArgList &Args,
|
2021-02-25 06:39:55 +08:00
|
|
|
StringRef Component,
|
|
|
|
FileType Type) const {
|
|
|
|
std::string CRTAbsolutePath = getCompilerRT(Args, Component, Type);
|
|
|
|
return llvm::sys::path::filename(CRTAbsolutePath).str();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string ToolChain::buildCompilerRTBasename(const llvm::opt::ArgList &Args,
|
|
|
|
StringRef Component,
|
|
|
|
FileType Type,
|
|
|
|
bool AddArch) const {
|
2021-02-24 09:38:16 +08:00
|
|
|
const llvm::Triple &TT = getTriple();
|
2016-09-01 03:27:07 +08:00
|
|
|
bool IsITANMSVCWindows =
|
2016-07-28 07:01:55 +08:00
|
|
|
TT.isWindowsMSVCEnvironment() || TT.isWindowsItaniumEnvironment();
|
2015-10-02 00:54:58 +08:00
|
|
|
|
2019-03-12 10:12:48 +08:00
|
|
|
const char *Prefix =
|
|
|
|
IsITANMSVCWindows || Type == ToolChain::FT_Object ? "" : "lib";
|
|
|
|
const char *Suffix;
|
|
|
|
switch (Type) {
|
|
|
|
case ToolChain::FT_Object:
|
|
|
|
Suffix = IsITANMSVCWindows ? ".obj" : ".o";
|
|
|
|
break;
|
|
|
|
case ToolChain::FT_Static:
|
|
|
|
Suffix = IsITANMSVCWindows ? ".lib" : ".a";
|
|
|
|
break;
|
|
|
|
case ToolChain::FT_Shared:
|
2021-02-25 06:39:55 +08:00
|
|
|
Suffix = TT.isOSWindows()
|
|
|
|
? (TT.isWindowsGNUEnvironment() ? ".dll.a" : ".lib")
|
2019-03-12 10:12:48 +08:00
|
|
|
: ".so";
|
|
|
|
break;
|
|
|
|
}
|
2015-10-02 00:54:58 +08:00
|
|
|
|
[Windows] Autolink with basenames and add libdir to libpath
Prior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.
These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
ago it was suggested that we use this for ASan, and apparently I felt
the same way back then:
https://reviews.llvm.org/D4428#56536
This is also consistent with how all other autolinking usage works for
PS4, Mac, and Windows: they all use basenames, not paths.
To keep things working for people using the standard GCC driver
workflow, the driver now adds the resource directory to the linker
library search path when it calls the linker. This is enough to make
check-ubsan pass, and seems like a generally good thing.
Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D65543
2019-08-01 05:52:00 +08:00
|
|
|
std::string ArchAndEnv;
|
|
|
|
if (AddArch) {
|
2021-02-24 09:38:16 +08:00
|
|
|
StringRef Arch = getArchNameForCompilerRTLib(*this, Args);
|
[Windows] Autolink with basenames and add libdir to libpath
Prior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.
These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
ago it was suggested that we use this for ASan, and apparently I felt
the same way back then:
https://reviews.llvm.org/D4428#56536
This is also consistent with how all other autolinking usage works for
PS4, Mac, and Windows: they all use basenames, not paths.
To keep things working for people using the standard GCC driver
workflow, the driver now adds the resource directory to the linker
library search path when it calls the linker. This is enough to make
check-ubsan pass, and seems like a generally good thing.
Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D65543
2019-08-01 05:52:00 +08:00
|
|
|
const char *Env = TT.isAndroid() ? "-android" : "";
|
|
|
|
ArchAndEnv = ("-" + Arch + Env).str();
|
|
|
|
}
|
|
|
|
return (Prefix + Twine("clang_rt.") + Component + ArchAndEnv + Suffix).str();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string ToolChain::getCompilerRT(const ArgList &Args, StringRef Component,
|
|
|
|
FileType Type) const {
|
|
|
|
// Check for runtime files in the new layout without the architecture first.
|
|
|
|
std::string CRTBasename =
|
2021-02-25 06:39:55 +08:00
|
|
|
buildCompilerRTBasename(Args, Component, Type, /*AddArch=*/false);
|
2018-08-23 06:56:46 +08:00
|
|
|
for (const auto &LibPath : getLibraryPaths()) {
|
|
|
|
SmallString<128> P(LibPath);
|
[Windows] Autolink with basenames and add libdir to libpath
Prior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.
These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
ago it was suggested that we use this for ASan, and apparently I felt
the same way back then:
https://reviews.llvm.org/D4428#56536
This is also consistent with how all other autolinking usage works for
PS4, Mac, and Windows: they all use basenames, not paths.
To keep things working for people using the standard GCC driver
workflow, the driver now adds the resource directory to the linker
library search path when it calls the linker. This is enough to make
check-ubsan pass, and seems like a generally good thing.
Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D65543
2019-08-01 05:52:00 +08:00
|
|
|
llvm::sys::path::append(P, CRTBasename);
|
2018-08-23 06:56:46 +08:00
|
|
|
if (getVFS().exists(P))
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(P.str());
|
2018-06-28 11:11:52 +08:00
|
|
|
}
|
|
|
|
|
[Windows] Autolink with basenames and add libdir to libpath
Prior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.
These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
ago it was suggested that we use this for ASan, and apparently I felt
the same way back then:
https://reviews.llvm.org/D4428#56536
This is also consistent with how all other autolinking usage works for
PS4, Mac, and Windows: they all use basenames, not paths.
To keep things working for people using the standard GCC driver
workflow, the driver now adds the resource directory to the linker
library search path when it calls the linker. This is enough to make
check-ubsan pass, and seems like a generally good thing.
Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D65543
2019-08-01 05:52:00 +08:00
|
|
|
// Fall back to the old expected compiler-rt name if the new one does not
|
|
|
|
// exist.
|
2021-02-25 06:39:55 +08:00
|
|
|
CRTBasename =
|
|
|
|
buildCompilerRTBasename(Args, Component, Type, /*AddArch=*/true);
|
2017-08-10 12:16:38 +08:00
|
|
|
SmallString<128> Path(getCompilerRTPath());
|
[Windows] Autolink with basenames and add libdir to libpath
Prior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.
These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
ago it was suggested that we use this for ASan, and apparently I felt
the same way back then:
https://reviews.llvm.org/D4428#56536
This is also consistent with how all other autolinking usage works for
PS4, Mac, and Windows: they all use basenames, not paths.
To keep things working for people using the standard GCC driver
workflow, the driver now adds the resource directory to the linker
library search path when it calls the linker. This is enough to make
check-ubsan pass, and seems like a generally good thing.
Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D65543
2019-08-01 05:52:00 +08:00
|
|
|
llvm::sys::path::append(Path, CRTBasename);
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(Path.str());
|
2015-10-02 00:54:58 +08:00
|
|
|
}
|
|
|
|
|
2016-07-28 07:01:55 +08:00
|
|
|
const char *ToolChain::getCompilerRTArgString(const llvm::opt::ArgList &Args,
|
|
|
|
StringRef Component,
|
2019-03-12 10:12:48 +08:00
|
|
|
FileType Type) const {
|
|
|
|
return Args.MakeArgString(getCompilerRT(Args, Component, Type));
|
2015-10-22 14:15:31 +08:00
|
|
|
}
|
|
|
|
|
2021-04-23 04:44:46 +08:00
|
|
|
std::string ToolChain::getRuntimePath() const {
|
|
|
|
SmallString<128> P(D.ResourceDir);
|
2021-04-28 13:31:36 +08:00
|
|
|
llvm::sys::path::append(P, "lib", getTripleString());
|
2021-04-23 04:44:46 +08:00
|
|
|
return std::string(P.str());
|
2019-05-26 11:39:07 +08:00
|
|
|
}
|
|
|
|
|
2021-04-23 04:44:46 +08:00
|
|
|
std::string ToolChain::getStdlibPath() const {
|
|
|
|
SmallString<128> P(D.Dir);
|
2021-04-28 13:31:36 +08:00
|
|
|
llvm::sys::path::append(P, "..", "lib", getTripleString());
|
2021-04-23 04:44:46 +08:00
|
|
|
return std::string(P.str());
|
2019-05-26 11:39:07 +08:00
|
|
|
}
|
|
|
|
|
2017-03-04 07:20:49 +08:00
|
|
|
std::string ToolChain::getArchSpecificLibPath() const {
|
|
|
|
SmallString<128> Path(getDriver().ResourceDir);
|
[Sanitizers] Basic Solaris sanitizer support (PR 33274)
Summary:
This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary
to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898,
https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900).
A few features of note:
* While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places
the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to
the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes
them agree on compiler-rt's idea.
* While Solaris ld accepts a considerable number of GNU ld options for compatibility,
it only does so for the double-dash forms. clang unfortunately is inconsistent here
and sometimes uses the double-dash form, sometimes the single-dash one that
confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash
form that should always work.
* As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the
__start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm
including additional runtime libs into the link that provide them.
* One test uses -fstack-protector, but unlike other systems libssp hasn't been folded
into Solaris libc, but needs to be linked with separately.
* For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but
sparc (which requires additional compiler-rt changes not yet submitted) fails miserably
due to a llvmsparc backend limitation:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
However, inside the gcc tree, Solaris/sparc asan works almost as well as x86.
Reviewers: rsmith, alekseyshl
Reviewed By: alekseyshl
Subscribers: jyknight, fedor.sergeev, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40903
llvm-svn: 324296
2018-02-06 07:59:13 +08:00
|
|
|
llvm::sys::path::append(Path, "lib", getOSLibName(),
|
2017-03-04 07:20:49 +08:00
|
|
|
llvm::Triple::getArchTypeName(getArch()));
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(Path.str());
|
2017-03-04 07:20:49 +08:00
|
|
|
}
|
|
|
|
|
2015-10-22 14:15:31 +08:00
|
|
|
bool ToolChain::needsProfileRT(const ArgList &Args) {
|
2019-07-12 03:06:38 +08:00
|
|
|
if (Args.hasArg(options::OPT_noprofilelib))
|
|
|
|
return false;
|
|
|
|
|
2020-05-09 14:13:19 +08:00
|
|
|
return Args.hasArg(options::OPT_fprofile_generate) ||
|
|
|
|
Args.hasArg(options::OPT_fprofile_generate_EQ) ||
|
|
|
|
Args.hasArg(options::OPT_fcs_profile_generate) ||
|
|
|
|
Args.hasArg(options::OPT_fcs_profile_generate_EQ) ||
|
|
|
|
Args.hasArg(options::OPT_fprofile_instr_generate) ||
|
|
|
|
Args.hasArg(options::OPT_fprofile_instr_generate_EQ) ||
|
|
|
|
Args.hasArg(options::OPT_fcreate_profile) ||
|
|
|
|
Args.hasArg(options::OPT_forder_file_instrumentation);
|
2015-10-22 14:15:31 +08:00
|
|
|
}
|
|
|
|
|
2018-12-04 04:53:58 +08:00
|
|
|
bool ToolChain::needsGCovInstrumentation(const llvm::opt::ArgList &Args) {
|
2020-05-09 07:14:41 +08:00
|
|
|
return Args.hasArg(options::OPT_coverage) ||
|
|
|
|
Args.hasFlag(options::OPT_fprofile_arcs, options::OPT_fno_profile_arcs,
|
|
|
|
false);
|
2018-12-04 04:53:58 +08:00
|
|
|
}
|
|
|
|
|
2013-03-24 23:06:53 +08:00
|
|
|
Tool *ToolChain::SelectTool(const JobAction &JA) const {
|
2019-06-10 21:12:43 +08:00
|
|
|
if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return getFlang();
|
2015-10-22 14:15:31 +08:00
|
|
|
if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
|
2013-03-20 11:05:54 +08:00
|
|
|
Action::ActionClass AC = JA.getKind();
|
|
|
|
if (AC == Action::AssembleJobClass && useIntegratedAs())
|
2013-03-24 23:06:53 +08:00
|
|
|
return getClangAs();
|
|
|
|
return getTool(AC);
|
2013-03-19 04:48:54 +08:00
|
|
|
}
|
|
|
|
|
2010-07-15 02:46:23 +08:00
|
|
|
std::string ToolChain::GetFilePath(const char *Name) const {
|
2018-10-26 16:33:29 +08:00
|
|
|
return D.GetFilePath(Name, *this);
|
2009-03-16 13:25:36 +08:00
|
|
|
}
|
|
|
|
|
2012-10-04 03:52:37 +08:00
|
|
|
std::string ToolChain::GetProgramPath(const char *Name) const {
|
|
|
|
return D.GetProgramPath(Name, *this);
|
2009-03-16 13:25:36 +08:00
|
|
|
}
|
2010-08-02 13:43:56 +08:00
|
|
|
|
2020-11-24 23:59:57 +08:00
|
|
|
std::string ToolChain::GetLinkerPath(bool *LinkerIsLLD,
|
|
|
|
bool *LinkerIsLLDDarwinNew) const {
|
clang+lld: Improve clang+ld.darwinnew.lld interaction, pass -demangle
This patch:
- adds an ld64.lld.darwinnew symlink for lld, to go with f2710d4b576,
so that `clang -fuse-ld=lld.darwinnew` can be used to test new
Mach-O lld while it's in bring-up. (The expectation is that we'll
remove this again once new Mach-O lld is the defauld and only Mach-O
lld.)
- lets the clang driver know if the linker is lld (currently
only triggered if `-fuse-ld=lld` or `-fuse-ld=lld.darwinnew` is
passed). Currently only used for the next point, but could be used
to implement other features that need close coordination between
compiler and linker, e.g. having a diag for calling `clang++` instead
of `clang` when link errors are caused by a missing C++ stdlib.
- lets the clang driver pass `-demangle` to Mach-O lld (both old and
new), in addition to ld64
- implements -demangle for new Mach-O lld
- changes demangleItanium() to accept _Z, __Z, ___Z, ____Z prefixes
(and updates one test added in D68014). Mach-O has an extra
underscore for symbols, and the three (or, on Mach-O, four)
underscores are used for block names.
Differential Revision: https://reviews.llvm.org/D91884
2020-11-21 02:57:44 +08:00
|
|
|
if (LinkerIsLLD)
|
|
|
|
*LinkerIsLLD = false;
|
2020-11-24 23:59:57 +08:00
|
|
|
if (LinkerIsLLDDarwinNew)
|
|
|
|
*LinkerIsLLDDarwinNew = false;
|
clang+lld: Improve clang+ld.darwinnew.lld interaction, pass -demangle
This patch:
- adds an ld64.lld.darwinnew symlink for lld, to go with f2710d4b576,
so that `clang -fuse-ld=lld.darwinnew` can be used to test new
Mach-O lld while it's in bring-up. (The expectation is that we'll
remove this again once new Mach-O lld is the defauld and only Mach-O
lld.)
- lets the clang driver know if the linker is lld (currently
only triggered if `-fuse-ld=lld` or `-fuse-ld=lld.darwinnew` is
passed). Currently only used for the next point, but could be used
to implement other features that need close coordination between
compiler and linker, e.g. having a diag for calling `clang++` instead
of `clang` when link errors are caused by a missing C++ stdlib.
- lets the clang driver pass `-demangle` to Mach-O lld (both old and
new), in addition to ld64
- implements -demangle for new Mach-O lld
- changes demangleItanium() to accept _Z, __Z, ___Z, ____Z prefixes
(and updates one test added in D68014). Mach-O has an extra
underscore for symbols, and the three (or, on Mach-O, four)
underscores are used for block names.
Differential Revision: https://reviews.llvm.org/D91884
2020-11-21 02:57:44 +08:00
|
|
|
|
2020-07-21 00:34:39 +08:00
|
|
|
// Get -fuse-ld= first to prevent -Wunused-command-line-argument. -fuse-ld= is
|
|
|
|
// considered as the linker flavor, e.g. "bfd", "gold", or "lld".
|
2021-03-18 16:05:14 +08:00
|
|
|
const Arg* A = Args.getLastArg(options::OPT_fuse_ld_EQ);
|
|
|
|
StringRef UseLinker = A ? A->getValue() : CLANG_DEFAULT_LINKER;
|
2016-12-15 00:46:50 +08:00
|
|
|
|
2020-07-21 00:34:39 +08:00
|
|
|
// --ld-path= takes precedence over -fuse-ld= and specifies the executable
|
|
|
|
// name. -B, COMPILER_PATH and PATH and consulted if the value does not
|
|
|
|
// contain a path component separator.
|
|
|
|
if (const Arg *A = Args.getLastArg(options::OPT_ld_path_EQ)) {
|
|
|
|
std::string Path(A->getValue());
|
|
|
|
if (!Path.empty()) {
|
|
|
|
if (llvm::sys::path::parent_path(Path).empty())
|
|
|
|
Path = GetProgramPath(A->getValue());
|
|
|
|
if (llvm::sys::fs::can_execute(Path))
|
|
|
|
return std::string(Path);
|
|
|
|
}
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_linker_name) << A->getAsString(Args);
|
|
|
|
return GetProgramPath(getDefaultLinker());
|
|
|
|
}
|
|
|
|
// If we're passed -fuse-ld= with no argument, or with the argument ld,
|
|
|
|
// then use whatever the default system linker is.
|
2020-08-14 04:42:58 +08:00
|
|
|
if (UseLinker.empty() || UseLinker == "ld") {
|
|
|
|
const char *DefaultLinker = getDefaultLinker();
|
|
|
|
if (llvm::sys::path::is_absolute(DefaultLinker))
|
|
|
|
return std::string(DefaultLinker);
|
|
|
|
else
|
|
|
|
return GetProgramPath(DefaultLinker);
|
|
|
|
}
|
2020-07-21 00:34:39 +08:00
|
|
|
|
|
|
|
// Extending -fuse-ld= to an absolute or relative path is unexpected. Checking
|
|
|
|
// for the linker flavor is brittle. In addition, prepending "ld." or "ld64."
|
|
|
|
// to a relative path is surprising. This is more complex due to priorities
|
|
|
|
// among -B, COMPILER_PATH and PATH. --ld-path= should be used instead.
|
|
|
|
if (UseLinker.find('/') != StringRef::npos)
|
2020-09-20 06:49:44 +08:00
|
|
|
getDriver().Diag(diag::warn_drv_fuse_ld_path);
|
2020-07-21 00:34:39 +08:00
|
|
|
|
2016-12-15 00:46:50 +08:00
|
|
|
if (llvm::sys::path::is_absolute(UseLinker)) {
|
|
|
|
// If we're passed what looks like an absolute path, don't attempt to
|
|
|
|
// second-guess that.
|
2018-02-27 10:51:30 +08:00
|
|
|
if (llvm::sys::fs::can_execute(UseLinker))
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(UseLinker);
|
2016-12-15 00:46:50 +08:00
|
|
|
} else {
|
2017-10-16 01:53:45 +08:00
|
|
|
llvm::SmallString<8> LinkerName;
|
|
|
|
if (Triple.isOSDarwin())
|
|
|
|
LinkerName.append("ld64.");
|
|
|
|
else
|
|
|
|
LinkerName.append("ld.");
|
2016-12-15 00:46:50 +08:00
|
|
|
LinkerName.append(UseLinker);
|
|
|
|
|
|
|
|
std::string LinkerPath(GetProgramPath(LinkerName.c_str()));
|
clang+lld: Improve clang+ld.darwinnew.lld interaction, pass -demangle
This patch:
- adds an ld64.lld.darwinnew symlink for lld, to go with f2710d4b576,
so that `clang -fuse-ld=lld.darwinnew` can be used to test new
Mach-O lld while it's in bring-up. (The expectation is that we'll
remove this again once new Mach-O lld is the defauld and only Mach-O
lld.)
- lets the clang driver know if the linker is lld (currently
only triggered if `-fuse-ld=lld` or `-fuse-ld=lld.darwinnew` is
passed). Currently only used for the next point, but could be used
to implement other features that need close coordination between
compiler and linker, e.g. having a diag for calling `clang++` instead
of `clang` when link errors are caused by a missing C++ stdlib.
- lets the clang driver pass `-demangle` to Mach-O lld (both old and
new), in addition to ld64
- implements -demangle for new Mach-O lld
- changes demangleItanium() to accept _Z, __Z, ___Z, ____Z prefixes
(and updates one test added in D68014). Mach-O has an extra
underscore for symbols, and the three (or, on Mach-O, four)
underscores are used for block names.
Differential Revision: https://reviews.llvm.org/D91884
2020-11-21 02:57:44 +08:00
|
|
|
if (llvm::sys::fs::can_execute(LinkerPath)) {
|
2021-03-03 01:50:51 +08:00
|
|
|
// FIXME: Remove LinkerIsLLDDarwinNew once there's only one MachO lld.
|
clang+lld: Improve clang+ld.darwinnew.lld interaction, pass -demangle
This patch:
- adds an ld64.lld.darwinnew symlink for lld, to go with f2710d4b576,
so that `clang -fuse-ld=lld.darwinnew` can be used to test new
Mach-O lld while it's in bring-up. (The expectation is that we'll
remove this again once new Mach-O lld is the defauld and only Mach-O
lld.)
- lets the clang driver know if the linker is lld (currently
only triggered if `-fuse-ld=lld` or `-fuse-ld=lld.darwinnew` is
passed). Currently only used for the next point, but could be used
to implement other features that need close coordination between
compiler and linker, e.g. having a diag for calling `clang++` instead
of `clang` when link errors are caused by a missing C++ stdlib.
- lets the clang driver pass `-demangle` to Mach-O lld (both old and
new), in addition to ld64
- implements -demangle for new Mach-O lld
- changes demangleItanium() to accept _Z, __Z, ___Z, ____Z prefixes
(and updates one test added in D68014). Mach-O has an extra
underscore for symbols, and the three (or, on Mach-O, four)
underscores are used for block names.
Differential Revision: https://reviews.llvm.org/D91884
2020-11-21 02:57:44 +08:00
|
|
|
if (LinkerIsLLD)
|
2021-03-03 01:50:51 +08:00
|
|
|
*LinkerIsLLD = UseLinker == "lld" || UseLinker == "lld.darwinold";
|
2020-11-24 23:59:57 +08:00
|
|
|
if (LinkerIsLLDDarwinNew)
|
2021-03-03 01:50:51 +08:00
|
|
|
*LinkerIsLLDDarwinNew = UseLinker == "lld";
|
2016-12-15 00:46:50 +08:00
|
|
|
return LinkerPath;
|
clang+lld: Improve clang+ld.darwinnew.lld interaction, pass -demangle
This patch:
- adds an ld64.lld.darwinnew symlink for lld, to go with f2710d4b576,
so that `clang -fuse-ld=lld.darwinnew` can be used to test new
Mach-O lld while it's in bring-up. (The expectation is that we'll
remove this again once new Mach-O lld is the defauld and only Mach-O
lld.)
- lets the clang driver know if the linker is lld (currently
only triggered if `-fuse-ld=lld` or `-fuse-ld=lld.darwinnew` is
passed). Currently only used for the next point, but could be used
to implement other features that need close coordination between
compiler and linker, e.g. having a diag for calling `clang++` instead
of `clang` when link errors are caused by a missing C++ stdlib.
- lets the clang driver pass `-demangle` to Mach-O lld (both old and
new), in addition to ld64
- implements -demangle for new Mach-O lld
- changes demangleItanium() to accept _Z, __Z, ___Z, ____Z prefixes
(and updates one test added in D68014). Mach-O has an extra
underscore for symbols, and the three (or, on Mach-O, four)
underscores are used for block names.
Differential Revision: https://reviews.llvm.org/D91884
2020-11-21 02:57:44 +08:00
|
|
|
}
|
2016-12-15 00:46:50 +08:00
|
|
|
}
|
2014-06-26 22:23:45 +08:00
|
|
|
|
2016-12-15 00:46:50 +08:00
|
|
|
if (A)
|
2014-06-26 22:23:45 +08:00
|
|
|
getDriver().Diag(diag::err_drv_invalid_linker_name) << A->getAsString(Args);
|
|
|
|
|
2016-12-15 00:46:50 +08:00
|
|
|
return GetProgramPath(getDefaultLinker());
|
2014-06-26 22:23:45 +08:00
|
|
|
}
|
|
|
|
|
2020-05-28 02:49:25 +08:00
|
|
|
std::string ToolChain::GetStaticLibToolPath() const {
|
|
|
|
// TODO: Add support for static lib archiving on Windows
|
|
|
|
return GetProgramPath("llvm-ar");
|
|
|
|
}
|
|
|
|
|
2016-10-08 05:41:00 +08:00
|
|
|
types::ID ToolChain::LookupTypeForExtension(StringRef Ext) const {
|
2019-06-10 21:12:43 +08:00
|
|
|
types::ID id = types::lookupTypeForExtension(Ext);
|
|
|
|
|
|
|
|
// Flang always runs the preprocessor and has no notion of "preprocessed
|
|
|
|
// fortran". Here, TY_PP_Fortran is coerced to TY_Fortran to avoid treating
|
|
|
|
// them differently.
|
|
|
|
if (D.IsFlangMode() && id == types::TY_PP_Fortran)
|
|
|
|
id = types::TY_Fortran;
|
|
|
|
|
|
|
|
return id;
|
2010-08-02 13:43:56 +08:00
|
|
|
}
|
2010-08-24 06:35:37 +08:00
|
|
|
|
2010-09-17 08:24:52 +08:00
|
|
|
bool ToolChain::HasNativeLLVMSupport() const {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-12-17 19:11:25 +08:00
|
|
|
bool ToolChain::isCrossCompiling() const {
|
|
|
|
llvm::Triple HostTriple(LLVM_HOST_TRIPLE);
|
|
|
|
switch (HostTriple.getArch()) {
|
2013-12-18 01:25:19 +08:00
|
|
|
// The A32/T32/T16 instruction sets are not separate architectures in this
|
|
|
|
// context.
|
|
|
|
case llvm::Triple::arm:
|
2014-03-28 22:40:46 +08:00
|
|
|
case llvm::Triple::armeb:
|
2013-12-18 01:25:19 +08:00
|
|
|
case llvm::Triple::thumb:
|
2014-03-28 22:40:46 +08:00
|
|
|
case llvm::Triple::thumbeb:
|
|
|
|
return getArch() != llvm::Triple::arm && getArch() != llvm::Triple::thumb &&
|
|
|
|
getArch() != llvm::Triple::armeb && getArch() != llvm::Triple::thumbeb;
|
2013-12-18 01:25:19 +08:00
|
|
|
default:
|
|
|
|
return HostTriple.getArch() != getArch();
|
2013-12-17 19:11:25 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-06-20 14:18:46 +08:00
|
|
|
ObjCRuntime ToolChain::getDefaultObjCRuntime(bool isNonFragile) const {
|
2012-07-04 04:49:52 +08:00
|
|
|
return ObjCRuntime(isNonFragile ? ObjCRuntime::GNUstep : ObjCRuntime::GCC,
|
2012-06-20 14:18:46 +08:00
|
|
|
VersionTuple());
|
2011-07-06 08:26:06 +08:00
|
|
|
}
|
|
|
|
|
2017-11-29 15:25:12 +08:00
|
|
|
llvm::ExceptionHandling
|
|
|
|
ToolChain::GetExceptionModel(const llvm::opt::ArgList &Args) const {
|
|
|
|
return llvm::ExceptionHandling::None;
|
|
|
|
}
|
|
|
|
|
2014-10-04 05:57:44 +08:00
|
|
|
bool ToolChain::isThreadModelSupported(const StringRef Model) const {
|
|
|
|
if (Model == "single") {
|
2015-09-04 06:51:53 +08:00
|
|
|
// FIXME: 'single' is only supported on ARM and WebAssembly so far.
|
2014-10-04 05:57:44 +08:00
|
|
|
return Triple.getArch() == llvm::Triple::arm ||
|
|
|
|
Triple.getArch() == llvm::Triple::armeb ||
|
|
|
|
Triple.getArch() == llvm::Triple::thumb ||
|
2020-07-07 04:34:16 +08:00
|
|
|
Triple.getArch() == llvm::Triple::thumbeb || Triple.isWasm();
|
2014-10-04 05:57:44 +08:00
|
|
|
} else if (Model == "posix")
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-11-16 08:53:35 +08:00
|
|
|
std::string ToolChain::ComputeLLVMTriple(const ArgList &Args,
|
2011-09-21 04:44:06 +08:00
|
|
|
types::ID InputType) const {
|
2010-08-24 06:35:37 +08:00
|
|
|
switch (getTriple().getArch()) {
|
|
|
|
default:
|
|
|
|
return getTripleString();
|
|
|
|
|
2013-11-16 08:53:35 +08:00
|
|
|
case llvm::Triple::x86_64: {
|
|
|
|
llvm::Triple Triple = getTriple();
|
2014-01-16 16:48:16 +08:00
|
|
|
if (!Triple.isOSBinFormatMachO())
|
2013-11-16 08:53:35 +08:00
|
|
|
return getTripleString();
|
|
|
|
|
|
|
|
if (Arg *A = Args.getLastArg(options::OPT_march_EQ)) {
|
|
|
|
// x86_64h goes in the triple. Other -march options just use the
|
|
|
|
// vanilla triple we already have.
|
|
|
|
StringRef MArch = A->getValue();
|
|
|
|
if (MArch == "x86_64h")
|
|
|
|
Triple.setArchName(MArch);
|
|
|
|
}
|
|
|
|
return Triple.getTriple();
|
|
|
|
}
|
2014-07-24 18:25:34 +08:00
|
|
|
case llvm::Triple::aarch64: {
|
|
|
|
llvm::Triple Triple = getTriple();
|
|
|
|
if (!Triple.isOSBinFormatMachO())
|
|
|
|
return getTripleString();
|
|
|
|
|
2020-09-03 23:43:21 +08:00
|
|
|
if (Triple.isArm64e())
|
|
|
|
return getTripleString();
|
|
|
|
|
2014-07-24 18:25:34 +08:00
|
|
|
// FIXME: older versions of ld64 expect the "arm64" component in the actual
|
|
|
|
// triple string and query it to determine whether an LTO file can be
|
|
|
|
// handled. Remove this when we don't care any more.
|
|
|
|
Triple.setArchName("arm64");
|
|
|
|
return Triple.getTriple();
|
|
|
|
}
|
2018-09-18 17:34:39 +08:00
|
|
|
case llvm::Triple::aarch64_32:
|
|
|
|
return getTripleString();
|
2010-08-24 06:35:37 +08:00
|
|
|
case llvm::Triple::arm:
|
2014-03-28 22:40:46 +08:00
|
|
|
case llvm::Triple::armeb:
|
|
|
|
case llvm::Triple::thumb:
|
|
|
|
case llvm::Triple::thumbeb: {
|
2010-08-24 06:35:37 +08:00
|
|
|
llvm::Triple Triple = getTriple();
|
2021-03-09 20:06:59 +08:00
|
|
|
tools::arm::setArchNameInTriple(getDriver(), Args, InputType, Triple);
|
|
|
|
tools::arm::setFloatABIInTriple(getDriver(), Args, Triple);
|
2010-08-24 06:35:37 +08:00
|
|
|
return Triple.getTriple();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-07 06:36:24 +08:00
|
|
|
std::string ToolChain::ComputeEffectiveClangTriple(const ArgList &Args,
|
2011-09-21 04:44:06 +08:00
|
|
|
types::ID InputType) const {
|
|
|
|
return ComputeLLVMTriple(Args, InputType);
|
2010-08-24 06:35:37 +08:00
|
|
|
}
|
|
|
|
|
[Driver] Search computed sysroot for libc++ header paths
Summary:
The Android NDK's clang driver is used with an Android -target setting,
and the driver automatically finds the Android sysroot at a path
relative to the driver. The sysroot has the libc++ headers in it.
Remove Hurd::computeSysRoot as it is equivalent to the new
ToolChain::computeSysRoot method.
Fixes PR46213.
Reviewers: srhines, danalbert, #libc, kristina
Reviewed By: srhines, danalbert
Subscribers: ldionne, sthibaul, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81622
2020-06-11 08:08:04 +08:00
|
|
|
std::string ToolChain::computeSysRoot() const {
|
|
|
|
return D.SysRoot;
|
|
|
|
}
|
|
|
|
|
2011-11-04 15:12:53 +08:00
|
|
|
void ToolChain::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
// Each toolchain should provide the appropriate include flags.
|
|
|
|
}
|
|
|
|
|
[OpenMP] Extend CLANG target options with device offloading kind.
Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld
Reviewed By: hfinkel
Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits
Differential Revision: https://reviews.llvm.org/D29647
llvm-svn: 307272
2017-07-07 00:22:21 +08:00
|
|
|
void ToolChain::addClangTargetOptions(
|
|
|
|
const ArgList &DriverArgs, ArgStringList &CC1Args,
|
|
|
|
Action::OffloadKind DeviceOffloadKind) const {}
|
2012-06-19 09:26:10 +08:00
|
|
|
|
2014-03-29 21:16:12 +08:00
|
|
|
void ToolChain::addClangWarningOptions(ArgStringList &CC1Args) const {}
|
|
|
|
|
2016-07-28 07:01:55 +08:00
|
|
|
void ToolChain::addProfileRTLibs(const llvm::opt::ArgList &Args,
|
2015-10-22 14:15:31 +08:00
|
|
|
llvm::opt::ArgStringList &CmdArgs) const {
|
2020-05-09 14:13:19 +08:00
|
|
|
if (!needsProfileRT(Args) && !needsGCovInstrumentation(Args))
|
|
|
|
return;
|
2015-10-22 14:15:31 +08:00
|
|
|
|
2016-07-28 07:01:55 +08:00
|
|
|
CmdArgs.push_back(getCompilerRTArgString(Args, "profile"));
|
2015-10-22 14:15:31 +08:00
|
|
|
}
|
|
|
|
|
2011-12-08 07:03:15 +08:00
|
|
|
ToolChain::RuntimeLibType ToolChain::GetRuntimeLibType(
|
2015-10-22 14:15:31 +08:00
|
|
|
const ArgList &Args) const {
|
2021-02-11 00:40:07 +08:00
|
|
|
if (runtimeLibType)
|
|
|
|
return *runtimeLibType;
|
|
|
|
|
2016-07-27 16:15:54 +08:00
|
|
|
const Arg* A = Args.getLastArg(options::OPT_rtlib_EQ);
|
|
|
|
StringRef LibName = A ? A->getValue() : CLANG_DEFAULT_RTLIB;
|
|
|
|
|
2016-12-12 15:53:47 +08:00
|
|
|
// Only use "platform" in tests to override CLANG_DEFAULT_RTLIB!
|
2016-07-27 16:15:54 +08:00
|
|
|
if (LibName == "compiler-rt")
|
2021-02-11 00:40:07 +08:00
|
|
|
runtimeLibType = ToolChain::RLT_CompilerRT;
|
2016-07-27 16:15:54 +08:00
|
|
|
else if (LibName == "libgcc")
|
2021-02-11 00:40:07 +08:00
|
|
|
runtimeLibType = ToolChain::RLT_Libgcc;
|
2016-07-27 16:15:54 +08:00
|
|
|
else if (LibName == "platform")
|
2021-02-11 00:40:07 +08:00
|
|
|
runtimeLibType = GetDefaultRuntimeLibType();
|
|
|
|
else {
|
|
|
|
if (A)
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_rtlib_name)
|
|
|
|
<< A->getAsString(Args);
|
2016-07-27 16:15:54 +08:00
|
|
|
|
2021-02-11 00:40:07 +08:00
|
|
|
runtimeLibType = GetDefaultRuntimeLibType();
|
|
|
|
}
|
2011-12-08 07:03:15 +08:00
|
|
|
|
2021-02-11 00:40:07 +08:00
|
|
|
return *runtimeLibType;
|
2011-12-08 07:03:15 +08:00
|
|
|
}
|
|
|
|
|
2019-03-20 04:01:59 +08:00
|
|
|
ToolChain::UnwindLibType ToolChain::GetUnwindLibType(
|
|
|
|
const ArgList &Args) const {
|
2021-02-11 00:40:07 +08:00
|
|
|
if (unwindLibType)
|
|
|
|
return *unwindLibType;
|
|
|
|
|
2019-03-20 04:01:59 +08:00
|
|
|
const Arg *A = Args.getLastArg(options::OPT_unwindlib_EQ);
|
|
|
|
StringRef LibName = A ? A->getValue() : CLANG_DEFAULT_UNWINDLIB;
|
|
|
|
|
|
|
|
if (LibName == "none")
|
2021-02-11 00:40:07 +08:00
|
|
|
unwindLibType = ToolChain::UNW_None;
|
2019-03-20 04:01:59 +08:00
|
|
|
else if (LibName == "platform" || LibName == "") {
|
|
|
|
ToolChain::RuntimeLibType RtLibType = GetRuntimeLibType(Args);
|
2021-02-10 17:25:58 +08:00
|
|
|
if (RtLibType == ToolChain::RLT_CompilerRT) {
|
2021-05-27 23:47:20 +08:00
|
|
|
if (getTriple().isAndroid() || getTriple().isOSAIX())
|
2021-02-10 17:25:58 +08:00
|
|
|
unwindLibType = ToolChain::UNW_CompilerRT;
|
|
|
|
else
|
|
|
|
unwindLibType = ToolChain::UNW_None;
|
|
|
|
} else if (RtLibType == ToolChain::RLT_Libgcc)
|
2021-02-11 00:40:07 +08:00
|
|
|
unwindLibType = ToolChain::UNW_Libgcc;
|
2019-03-20 04:01:59 +08:00
|
|
|
} else if (LibName == "libunwind") {
|
|
|
|
if (GetRuntimeLibType(Args) == RLT_Libgcc)
|
|
|
|
getDriver().Diag(diag::err_drv_incompatible_unwindlib);
|
2021-02-11 00:40:07 +08:00
|
|
|
unwindLibType = ToolChain::UNW_CompilerRT;
|
2019-03-20 04:01:59 +08:00
|
|
|
} else if (LibName == "libgcc")
|
2021-02-11 00:40:07 +08:00
|
|
|
unwindLibType = ToolChain::UNW_Libgcc;
|
|
|
|
else {
|
|
|
|
if (A)
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_unwindlib_name)
|
|
|
|
<< A->getAsString(Args);
|
2019-03-20 04:01:59 +08:00
|
|
|
|
2021-02-11 00:40:07 +08:00
|
|
|
unwindLibType = GetDefaultUnwindLibType();
|
|
|
|
}
|
2019-03-20 04:01:59 +08:00
|
|
|
|
2021-02-11 00:40:07 +08:00
|
|
|
return *unwindLibType;
|
2019-03-20 04:01:59 +08:00
|
|
|
}
|
|
|
|
|
2010-09-15 07:12:35 +08:00
|
|
|
ToolChain::CXXStdlibType ToolChain::GetCXXStdlibType(const ArgList &Args) const{
|
2021-02-11 00:40:07 +08:00
|
|
|
if (cxxStdlibType)
|
|
|
|
return *cxxStdlibType;
|
|
|
|
|
2016-02-12 15:48:37 +08:00
|
|
|
const Arg *A = Args.getLastArg(options::OPT_stdlib_EQ);
|
2016-12-12 15:53:47 +08:00
|
|
|
StringRef LibName = A ? A->getValue() : CLANG_DEFAULT_CXX_STDLIB;
|
|
|
|
|
|
|
|
// Only use "platform" in tests to override CLANG_DEFAULT_CXX_STDLIB!
|
|
|
|
if (LibName == "libc++")
|
2021-02-11 00:40:07 +08:00
|
|
|
cxxStdlibType = ToolChain::CST_Libcxx;
|
2016-12-12 15:53:47 +08:00
|
|
|
else if (LibName == "libstdc++")
|
2021-02-11 00:40:07 +08:00
|
|
|
cxxStdlibType = ToolChain::CST_Libstdcxx;
|
2016-12-12 15:53:47 +08:00
|
|
|
else if (LibName == "platform")
|
2021-02-11 00:40:07 +08:00
|
|
|
cxxStdlibType = GetDefaultCXXStdlibType();
|
|
|
|
else {
|
|
|
|
if (A)
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_stdlib_name)
|
|
|
|
<< A->getAsString(Args);
|
2010-09-15 07:12:40 +08:00
|
|
|
|
2021-02-11 00:40:07 +08:00
|
|
|
cxxStdlibType = GetDefaultCXXStdlibType();
|
|
|
|
}
|
2016-02-12 15:48:37 +08:00
|
|
|
|
2021-02-11 00:40:07 +08:00
|
|
|
return *cxxStdlibType;
|
2010-09-15 07:12:35 +08:00
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Utility function to add a system include directory to CC1 arguments.
|
2011-12-18 07:10:01 +08:00
|
|
|
/*static*/ void ToolChain::addSystemInclude(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args,
|
|
|
|
const Twine &Path) {
|
|
|
|
CC1Args.push_back("-internal-isystem");
|
|
|
|
CC1Args.push_back(DriverArgs.MakeArgString(Path));
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Utility function to add a system include directory with extern "C"
|
2011-12-18 07:10:01 +08:00
|
|
|
/// semantics to CC1 arguments.
|
|
|
|
///
|
|
|
|
/// Note that this should be used rarely, and only for directories that
|
|
|
|
/// historically and for legacy reasons are treated as having implicit extern
|
|
|
|
/// "C" semantics. These semantics are *ignored* by and large today, but its
|
|
|
|
/// important to preserve the preprocessor changes resulting from the
|
|
|
|
/// classification.
|
|
|
|
/*static*/ void ToolChain::addExternCSystemInclude(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args,
|
|
|
|
const Twine &Path) {
|
|
|
|
CC1Args.push_back("-internal-externc-isystem");
|
|
|
|
CC1Args.push_back(DriverArgs.MakeArgString(Path));
|
|
|
|
}
|
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
void ToolChain::addExternCSystemIncludeIfExists(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args,
|
|
|
|
const Twine &Path) {
|
|
|
|
if (llvm::sys::fs::exists(Path))
|
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, Path);
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Utility function to add a list of system include directories to CC1.
|
2011-12-18 07:10:01 +08:00
|
|
|
/*static*/ void ToolChain::addSystemIncludes(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args,
|
|
|
|
ArrayRef<StringRef> Paths) {
|
2019-12-18 04:56:04 +08:00
|
|
|
for (const auto &Path : Paths) {
|
2011-12-18 07:10:01 +08:00
|
|
|
CC1Args.push_back("-internal-isystem");
|
2015-08-07 06:36:24 +08:00
|
|
|
CC1Args.push_back(DriverArgs.MakeArgString(Path));
|
2011-12-18 07:10:01 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-22 16:01:16 +08:00
|
|
|
std::string ToolChain::detectLibcxxVersion(StringRef IncludePath) const {
|
|
|
|
std::error_code EC;
|
|
|
|
int MaxVersion = 0;
|
|
|
|
std::string MaxVersionString;
|
|
|
|
SmallString<128> Path(IncludePath);
|
|
|
|
llvm::sys::path::append(Path, "c++");
|
|
|
|
for (llvm::vfs::directory_iterator LI = getVFS().dir_begin(Path, EC), LE;
|
|
|
|
!EC && LI != LE; LI = LI.increment(EC)) {
|
|
|
|
StringRef VersionText = llvm::sys::path::filename(LI->path());
|
|
|
|
int Version;
|
|
|
|
if (VersionText[0] == 'v' &&
|
|
|
|
!VersionText.slice(1, StringRef::npos).getAsInteger(10, Version)) {
|
|
|
|
if (Version > MaxVersion) {
|
|
|
|
MaxVersion = Version;
|
|
|
|
MaxVersionString = std::string(VersionText);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!MaxVersion)
|
|
|
|
return "";
|
|
|
|
return MaxVersionString;
|
|
|
|
}
|
|
|
|
|
2011-11-05 07:49:01 +08:00
|
|
|
void ToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
2011-11-04 15:43:33 +08:00
|
|
|
// Header search paths should be handled by each of the subclasses.
|
|
|
|
// Historically, they have not been, and instead have been handled inside of
|
|
|
|
// the CC1-layer frontend. As the logic is hoisted out, this generic function
|
|
|
|
// will slowly stop being called.
|
|
|
|
//
|
|
|
|
// While it is being called, replicate a bit of a hack to propagate the
|
|
|
|
// '-stdlib=' flag down to CC1 so that it can in turn customize the C++
|
|
|
|
// header search paths with it. Once all systems are overriding this
|
|
|
|
// function, the CC1 flag and this line can be removed.
|
2011-11-05 07:49:01 +08:00
|
|
|
DriverArgs.AddAllArgs(CC1Args, options::OPT_stdlib_EQ);
|
2010-09-15 07:12:35 +08:00
|
|
|
}
|
|
|
|
|
[Driver] Introduce -stdlib++-isystem
There are times when we wish to explicitly control the C++ standard
library search paths used by the driver. For example, when we're
building against the Android NDK, we might want to use the NDK's C++
headers (which have a custom inline namespace) even if we have C++
headers installed next to the driver. We might also be building against
a non-standard directory layout and wanting to specify the C++ standard
library include directories explicitly.
We could accomplish this by passing -nostdinc++ and adding an explicit
-isystem for our custom search directories. However, users of our
toolchain may themselves want to use -nostdinc++ and a custom C++ search
path (libc++'s build does this, for example), and our added -isystem
won't respect the -nostdinc++, leading to multiple C++ header
directories on the search path, which causes build failures.
Add a new driver option -stdlib++-isystem to support this use case.
Passing this option suppresses adding the default C++ library include
paths in the driver, and it also respects -nostdinc++ to allow users to
still override the C++ library paths themselves.
It's a bit unfortunate that we end up with both -stdlib++-isystem and
-cxx-isystem, but their semantics differ significantly. -cxx-isystem is
unaffected by -nostdinc++ and is added to the end of the search path
(which is not appropriate for C++ standard library headers, since they
often #include_next into other system headers), while -stdlib++-isystem
respects -nostdinc++, is added to the beginning of the search path, and
suppresses the default C++ library include paths.
Differential Revision: https://reviews.llvm.org/D64089
llvm-svn: 367982
2019-08-06 14:48:43 +08:00
|
|
|
void ToolChain::AddClangCXXStdlibIsystemArgs(
|
|
|
|
const llvm::opt::ArgList &DriverArgs,
|
|
|
|
llvm::opt::ArgStringList &CC1Args) const {
|
|
|
|
DriverArgs.ClaimAllArgs(options::OPT_stdlibxx_isystem);
|
2021-03-29 02:30:27 +08:00
|
|
|
if (!DriverArgs.hasArg(options::OPT_nostdinc, options::OPT_nostdincxx,
|
|
|
|
options::OPT_nostdlibinc))
|
[Driver] Introduce -stdlib++-isystem
There are times when we wish to explicitly control the C++ standard
library search paths used by the driver. For example, when we're
building against the Android NDK, we might want to use the NDK's C++
headers (which have a custom inline namespace) even if we have C++
headers installed next to the driver. We might also be building against
a non-standard directory layout and wanting to specify the C++ standard
library include directories explicitly.
We could accomplish this by passing -nostdinc++ and adding an explicit
-isystem for our custom search directories. However, users of our
toolchain may themselves want to use -nostdinc++ and a custom C++ search
path (libc++'s build does this, for example), and our added -isystem
won't respect the -nostdinc++, leading to multiple C++ header
directories on the search path, which causes build failures.
Add a new driver option -stdlib++-isystem to support this use case.
Passing this option suppresses adding the default C++ library include
paths in the driver, and it also respects -nostdinc++ to allow users to
still override the C++ library paths themselves.
It's a bit unfortunate that we end up with both -stdlib++-isystem and
-cxx-isystem, but their semantics differ significantly. -cxx-isystem is
unaffected by -nostdinc++ and is added to the end of the search path
(which is not appropriate for C++ standard library headers, since they
often #include_next into other system headers), while -stdlib++-isystem
respects -nostdinc++, is added to the beginning of the search path, and
suppresses the default C++ library include paths.
Differential Revision: https://reviews.llvm.org/D64089
llvm-svn: 367982
2019-08-06 14:48:43 +08:00
|
|
|
for (const auto &P :
|
|
|
|
DriverArgs.getAllArgValues(options::OPT_stdlibxx_isystem))
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, P);
|
|
|
|
}
|
|
|
|
|
2017-07-26 02:02:57 +08:00
|
|
|
bool ToolChain::ShouldLinkCXXStdlib(const llvm::opt::ArgList &Args) const {
|
|
|
|
return getDriver().CCCIsCXX() &&
|
|
|
|
!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
|
|
|
|
options::OPT_nostdlibxx);
|
|
|
|
}
|
|
|
|
|
2010-09-17 09:20:05 +08:00
|
|
|
void ToolChain::AddCXXStdlibLibArgs(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
2017-07-26 02:02:57 +08:00
|
|
|
assert(!Args.hasArg(options::OPT_nostdlibxx) &&
|
|
|
|
"should not have called this");
|
2010-09-15 07:12:35 +08:00
|
|
|
CXXStdlibType Type = GetCXXStdlibType(Args);
|
|
|
|
|
|
|
|
switch (Type) {
|
2010-09-15 07:12:40 +08:00
|
|
|
case ToolChain::CST_Libcxx:
|
|
|
|
CmdArgs.push_back("-lc++");
|
|
|
|
break;
|
|
|
|
|
2010-09-15 07:12:35 +08:00
|
|
|
case ToolChain::CST_Libstdcxx:
|
|
|
|
CmdArgs.push_back("-lstdc++");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2010-09-18 02:39:08 +08:00
|
|
|
|
2015-11-18 01:41:23 +08:00
|
|
|
void ToolChain::AddFilePathLibArgs(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
|
|
|
for (const auto &LibPath : getFilePaths())
|
2018-10-26 16:33:29 +08:00
|
|
|
if(LibPath.length() > 0)
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(StringRef("-L") + LibPath));
|
2015-11-18 01:41:23 +08:00
|
|
|
}
|
|
|
|
|
2010-09-18 02:39:08 +08:00
|
|
|
void ToolChain::AddCCKextLibArgs(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
|
|
|
CmdArgs.push_back("-lcc_kext");
|
|
|
|
}
|
2012-10-05 03:42:20 +08:00
|
|
|
|
2019-11-08 09:14:51 +08:00
|
|
|
bool ToolChain::isFastMathRuntimeAvailable(const ArgList &Args,
|
|
|
|
std::string &Path) const {
|
2014-03-26 02:02:07 +08:00
|
|
|
// Do not check for -fno-fast-math or -fno-unsafe-math when -Ofast passed
|
|
|
|
// (to keep the linker options consistent with gcc and clang itself).
|
|
|
|
if (!isOptimizationLevelFast(Args)) {
|
|
|
|
// Check if -ffast-math or -funsafe-math.
|
|
|
|
Arg *A =
|
2019-11-08 09:14:51 +08:00
|
|
|
Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
|
|
|
|
options::OPT_funsafe_math_optimizations,
|
|
|
|
options::OPT_fno_unsafe_math_optimizations);
|
2014-03-26 02:02:07 +08:00
|
|
|
|
|
|
|
if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
|
|
|
|
A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
|
|
|
|
return false;
|
|
|
|
}
|
2012-10-05 03:42:20 +08:00
|
|
|
// If crtfastmath.o exists add it to the arguments.
|
2019-11-08 09:14:51 +08:00
|
|
|
Path = GetFilePath("crtfastmath.o");
|
|
|
|
return (Path != "crtfastmath.o"); // Not found.
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ToolChain::addFastMathRuntimeIfAvailable(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
|
|
|
std::string Path;
|
|
|
|
if (isFastMathRuntimeAvailable(Args, Path)) {
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(Path));
|
|
|
|
return true;
|
|
|
|
}
|
2012-10-05 03:42:20 +08:00
|
|
|
|
2019-11-08 09:14:51 +08:00
|
|
|
return false;
|
2012-10-05 03:42:20 +08:00
|
|
|
}
|
2015-06-20 05:36:47 +08:00
|
|
|
|
|
|
|
SanitizerMask ToolChain::getSupportedSanitizers() const {
|
|
|
|
// Return sanitizers which don't require runtime support and are not
|
2015-09-11 03:18:05 +08:00
|
|
|
// platform dependent.
|
2018-03-21 05:08:59 +08:00
|
|
|
|
2020-08-15 05:05:57 +08:00
|
|
|
SanitizerMask Res =
|
|
|
|
(SanitizerKind::Undefined & ~SanitizerKind::Vptr &
|
|
|
|
~SanitizerKind::Function) |
|
|
|
|
(SanitizerKind::CFI & ~SanitizerKind::CFIICall) |
|
|
|
|
SanitizerKind::CFICastStrict | SanitizerKind::FloatDivideByZero |
|
|
|
|
SanitizerKind::UnsignedIntegerOverflow |
|
|
|
|
SanitizerKind::UnsignedShiftBase | SanitizerKind::ImplicitConversion |
|
|
|
|
SanitizerKind::Nullability | SanitizerKind::LocalBounds;
|
2015-09-11 03:18:05 +08:00
|
|
|
if (getTriple().getArch() == llvm::Triple::x86 ||
|
2016-08-09 05:14:15 +08:00
|
|
|
getTriple().getArch() == llvm::Triple::x86_64 ||
|
2020-07-07 04:34:16 +08:00
|
|
|
getTriple().getArch() == llvm::Triple::arm || getTriple().isWasm() ||
|
|
|
|
getTriple().isAArch64())
|
2019-03-01 18:05:15 +08:00
|
|
|
Res |= SanitizerKind::CFIICall;
|
2020-03-27 13:09:31 +08:00
|
|
|
if (getTriple().getArch() == llvm::Triple::x86_64 ||
|
2020-11-10 19:15:08 +08:00
|
|
|
getTriple().isAArch64(64) || getTriple().isRISCV())
|
2019-03-01 18:05:15 +08:00
|
|
|
Res |= SanitizerKind::ShadowCallStack;
|
2020-11-10 19:15:08 +08:00
|
|
|
if (getTriple().isAArch64(64))
|
2019-08-13 22:20:23 +08:00
|
|
|
Res |= SanitizerKind::MemTag;
|
2015-09-11 03:18:05 +08:00
|
|
|
return Res;
|
2015-06-20 05:36:47 +08:00
|
|
|
}
|
2015-11-18 06:28:46 +08:00
|
|
|
|
|
|
|
void ToolChain::AddCudaIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {}
|
2016-06-16 18:36:09 +08:00
|
|
|
|
2020-06-06 04:49:38 +08:00
|
|
|
void ToolChain::AddHIPIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {}
|
|
|
|
|
2021-02-17 02:43:03 +08:00
|
|
|
llvm::SmallVector<std::string, 12>
|
|
|
|
ToolChain::getHIPDeviceLibs(const ArgList &DriverArgs) const {
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
2016-06-16 18:36:09 +08:00
|
|
|
void ToolChain::AddIAMCUIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {}
|
Refactor how the MSVC toolchain searches for a compatibility version.
Summary:
The MSVC toolchain and Clang driver combination currently uses a fairly complex
sequence of steps to determine the MS compatibility version to pass to cc1.
There is some oddness in this sequence currently, with some code which inspects
flags in the toolchain, and some code which inspects the triple and local
environment in the driver code.
This change is an attempt to consolidate most of this logic so that
Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the
split, so any suggestions are welcome.
There are a few things you might want to watch for for specifically:
- On all platforms, if MSVC compatibility flags are provided (and valid), use
those.
- The fallback sequence should be the same as before, but is now consolidated
into MSVCToolChain::getMSVCVersion:
- Otherwise, try to use the Triple.
- Otherwise, on Windows, check the executable.
- Otherwise, on Windows or with --fms-extensions, default to 18.
- Otherwise, we can't determine the version.
- MSVCToolChain::ComputeEffectiveTriple no longer calls the base
ToolChain::ComputeEffectiveClangTriple. The only thing it would change for
Windows the architecture, which we don't care about for the compatibility
version.
- I'm not sure whether this is philosophically correct (but it should
be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not).
- Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look
like the effective triple was always being used previously anyhow.
Reviewers: hans, compnerd, llvm-commits, rnk
Subscribers: amccarth
Differential Revision: https://reviews.llvm.org/D27477
llvm-svn: 288998
2016-12-08 07:41:58 +08:00
|
|
|
|
|
|
|
static VersionTuple separateMSVCFullVersion(unsigned Version) {
|
|
|
|
if (Version < 100)
|
|
|
|
return VersionTuple(Version);
|
|
|
|
|
|
|
|
if (Version < 10000)
|
|
|
|
return VersionTuple(Version / 100, Version % 100);
|
|
|
|
|
|
|
|
unsigned Build = 0, Factor = 1;
|
|
|
|
for (; Version > 10000; Version = Version / 10, Factor = Factor * 10)
|
|
|
|
Build = Build + (Version % 10) * Factor;
|
|
|
|
return VersionTuple(Version / 100, Version % 100, Build);
|
|
|
|
}
|
|
|
|
|
|
|
|
VersionTuple
|
|
|
|
ToolChain::computeMSVCVersion(const Driver *D,
|
|
|
|
const llvm::opt::ArgList &Args) const {
|
|
|
|
const Arg *MSCVersion = Args.getLastArg(options::OPT_fmsc_version);
|
|
|
|
const Arg *MSCompatibilityVersion =
|
|
|
|
Args.getLastArg(options::OPT_fms_compatibility_version);
|
|
|
|
|
|
|
|
if (MSCVersion && MSCompatibilityVersion) {
|
|
|
|
if (D)
|
|
|
|
D->Diag(diag::err_drv_argument_not_allowed_with)
|
|
|
|
<< MSCVersion->getAsString(Args)
|
|
|
|
<< MSCompatibilityVersion->getAsString(Args);
|
|
|
|
return VersionTuple();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (MSCompatibilityVersion) {
|
|
|
|
VersionTuple MSVT;
|
|
|
|
if (MSVT.tryParse(MSCompatibilityVersion->getValue())) {
|
|
|
|
if (D)
|
|
|
|
D->Diag(diag::err_drv_invalid_value)
|
|
|
|
<< MSCompatibilityVersion->getAsString(Args)
|
|
|
|
<< MSCompatibilityVersion->getValue();
|
|
|
|
} else {
|
|
|
|
return MSVT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (MSCVersion) {
|
|
|
|
unsigned Version = 0;
|
|
|
|
if (StringRef(MSCVersion->getValue()).getAsInteger(10, Version)) {
|
|
|
|
if (D)
|
|
|
|
D->Diag(diag::err_drv_invalid_value)
|
|
|
|
<< MSCVersion->getAsString(Args) << MSCVersion->getValue();
|
|
|
|
} else {
|
|
|
|
return separateMSVCFullVersion(Version);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return VersionTuple();
|
|
|
|
}
|
2017-08-07 23:39:11 +08:00
|
|
|
|
2017-09-28 02:12:31 +08:00
|
|
|
llvm::opt::DerivedArgList *ToolChain::TranslateOpenMPTargetArgs(
|
2017-10-04 21:32:59 +08:00
|
|
|
const llvm::opt::DerivedArgList &Args, bool SameTripleAsHost,
|
|
|
|
SmallVectorImpl<llvm::opt::Arg *> &AllocatedArgs) const {
|
|
|
|
DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
|
|
|
|
const OptTable &Opts = getDriver().getOpts();
|
|
|
|
bool Modified = false;
|
|
|
|
|
|
|
|
// Handle -Xopenmp-target flags
|
2018-03-21 05:08:59 +08:00
|
|
|
for (auto *A : Args) {
|
2017-10-04 21:32:59 +08:00
|
|
|
// Exclude flags which may only apply to the host toolchain.
|
|
|
|
// Do not exclude flags when the host triple (AuxTriple)
|
|
|
|
// matches the current toolchain triple. If it is not present
|
|
|
|
// at all, target and host share a toolchain.
|
|
|
|
if (A->getOption().matches(options::OPT_m_Group)) {
|
|
|
|
if (SameTripleAsHost)
|
2017-08-07 23:39:11 +08:00
|
|
|
DAL->append(A);
|
2017-10-04 21:32:59 +08:00
|
|
|
else
|
|
|
|
Modified = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned Index;
|
|
|
|
unsigned Prev;
|
|
|
|
bool XOpenMPTargetNoTriple =
|
|
|
|
A->getOption().matches(options::OPT_Xopenmp_target);
|
|
|
|
|
|
|
|
if (A->getOption().matches(options::OPT_Xopenmp_target_EQ)) {
|
|
|
|
// Passing device args: -Xopenmp-target=<triple> -opt=val.
|
|
|
|
if (A->getValue(0) == getTripleString())
|
|
|
|
Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
|
|
|
|
else
|
2017-08-07 23:39:11 +08:00
|
|
|
continue;
|
2017-10-04 21:32:59 +08:00
|
|
|
} else if (XOpenMPTargetNoTriple) {
|
|
|
|
// Passing device args: -Xopenmp-target -opt=val.
|
|
|
|
Index = Args.getBaseArgs().MakeIndex(A->getValue(0));
|
|
|
|
} else {
|
2017-08-07 23:39:11 +08:00
|
|
|
DAL->append(A);
|
2017-10-04 21:32:59 +08:00
|
|
|
continue;
|
2017-08-07 23:39:11 +08:00
|
|
|
}
|
|
|
|
|
2017-10-04 21:32:59 +08:00
|
|
|
// Parse the argument to -Xopenmp-target.
|
|
|
|
Prev = Index;
|
|
|
|
std::unique_ptr<Arg> XOpenMPTargetArg(Opts.ParseOneArg(Args, Index));
|
|
|
|
if (!XOpenMPTargetArg || Index > Prev + 1) {
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_Xopenmp_target_with_args)
|
|
|
|
<< A->getAsString(Args);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (XOpenMPTargetNoTriple && XOpenMPTargetArg &&
|
|
|
|
Args.getAllArgValues(options::OPT_fopenmp_targets_EQ).size() != 1) {
|
|
|
|
getDriver().Diag(diag::err_drv_Xopenmp_target_missing_triple);
|
|
|
|
continue;
|
2017-08-14 15:44:05 +08:00
|
|
|
}
|
2017-10-04 21:32:59 +08:00
|
|
|
XOpenMPTargetArg->setBaseArg(A);
|
|
|
|
A = XOpenMPTargetArg.release();
|
|
|
|
AllocatedArgs.push_back(A);
|
|
|
|
DAL->append(A);
|
|
|
|
Modified = true;
|
2017-08-07 23:39:11 +08:00
|
|
|
}
|
|
|
|
|
2017-10-04 21:32:59 +08:00
|
|
|
if (Modified)
|
|
|
|
return DAL;
|
|
|
|
|
|
|
|
delete DAL;
|
2017-08-07 23:39:11 +08:00
|
|
|
return nullptr;
|
|
|
|
}
|
2020-03-20 05:11:35 +08:00
|
|
|
|
2020-03-24 02:23:09 +08:00
|
|
|
// TODO: Currently argument values separated by space e.g.
|
|
|
|
// -Xclang -mframe-pointer=no cannot be passed by -Xarch_. This should be
|
|
|
|
// fixed.
|
|
|
|
void ToolChain::TranslateXarchArgs(
|
|
|
|
const llvm::opt::DerivedArgList &Args, llvm::opt::Arg *&A,
|
|
|
|
llvm::opt::DerivedArgList *DAL,
|
|
|
|
SmallVectorImpl<llvm::opt::Arg *> *AllocatedArgs) const {
|
2020-03-20 05:11:35 +08:00
|
|
|
const OptTable &Opts = getDriver().getOpts();
|
2020-03-24 02:23:09 +08:00
|
|
|
unsigned ValuePos = 1;
|
|
|
|
if (A->getOption().matches(options::OPT_Xarch_device) ||
|
|
|
|
A->getOption().matches(options::OPT_Xarch_host))
|
|
|
|
ValuePos = 0;
|
|
|
|
|
|
|
|
unsigned Index = Args.getBaseArgs().MakeIndex(A->getValue(ValuePos));
|
2020-03-20 05:11:35 +08:00
|
|
|
unsigned Prev = Index;
|
|
|
|
std::unique_ptr<llvm::opt::Arg> XarchArg(Opts.ParseOneArg(Args, Index));
|
|
|
|
|
|
|
|
// If the argument parsing failed or more than one argument was
|
|
|
|
// consumed, the -Xarch_ argument's parameter tried to consume
|
|
|
|
// extra arguments. Emit an error and ignore.
|
|
|
|
//
|
|
|
|
// We also want to disallow any options which would alter the
|
|
|
|
// driver behavior; that isn't going to work in our model. We
|
2020-10-30 23:57:42 +08:00
|
|
|
// use options::NoXarchOption to control this.
|
2020-03-20 05:11:35 +08:00
|
|
|
if (!XarchArg || Index > Prev + 1) {
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_Xarch_argument_with_args)
|
|
|
|
<< A->getAsString(Args);
|
|
|
|
return;
|
2020-10-30 23:57:42 +08:00
|
|
|
} else if (XarchArg->getOption().hasFlag(options::NoXarchOption)) {
|
|
|
|
auto &Diags = getDriver().getDiags();
|
|
|
|
unsigned DiagID =
|
|
|
|
Diags.getCustomDiagID(DiagnosticsEngine::Error,
|
|
|
|
"invalid Xarch argument: '%0', not all driver "
|
|
|
|
"options can be forwared via Xarch argument");
|
|
|
|
Diags.Report(DiagID) << A->getAsString(Args);
|
2020-03-20 05:11:35 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
XarchArg->setBaseArg(A);
|
|
|
|
A = XarchArg.release();
|
2020-03-24 02:23:09 +08:00
|
|
|
if (!AllocatedArgs)
|
|
|
|
DAL->AddSynthesizedArg(A);
|
|
|
|
else
|
|
|
|
AllocatedArgs->push_back(A);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::opt::DerivedArgList *ToolChain::TranslateXarchArgs(
|
|
|
|
const llvm::opt::DerivedArgList &Args, StringRef BoundArch,
|
|
|
|
Action::OffloadKind OFK,
|
|
|
|
SmallVectorImpl<llvm::opt::Arg *> *AllocatedArgs) const {
|
|
|
|
DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
|
|
|
|
bool Modified = false;
|
|
|
|
|
|
|
|
bool IsGPU = OFK == Action::OFK_Cuda || OFK == Action::OFK_HIP;
|
|
|
|
for (Arg *A : Args) {
|
|
|
|
bool NeedTrans = false;
|
|
|
|
bool Skip = false;
|
|
|
|
if (A->getOption().matches(options::OPT_Xarch_device)) {
|
|
|
|
NeedTrans = IsGPU;
|
|
|
|
Skip = !IsGPU;
|
|
|
|
} else if (A->getOption().matches(options::OPT_Xarch_host)) {
|
|
|
|
NeedTrans = !IsGPU;
|
|
|
|
Skip = IsGPU;
|
|
|
|
} else if (A->getOption().matches(options::OPT_Xarch__) && IsGPU) {
|
|
|
|
// Do not translate -Xarch_ options for non CUDA/HIP toolchain since
|
|
|
|
// they may need special translation.
|
|
|
|
// Skip this argument unless the architecture matches BoundArch
|
|
|
|
if (BoundArch.empty() || A->getValue(0) != BoundArch)
|
|
|
|
Skip = true;
|
|
|
|
else
|
|
|
|
NeedTrans = true;
|
|
|
|
}
|
|
|
|
if (NeedTrans || Skip)
|
|
|
|
Modified = true;
|
|
|
|
if (NeedTrans)
|
|
|
|
TranslateXarchArgs(Args, A, DAL, AllocatedArgs);
|
|
|
|
if (!Skip)
|
|
|
|
DAL->append(A);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Modified)
|
|
|
|
return DAL;
|
|
|
|
|
|
|
|
delete DAL;
|
|
|
|
return nullptr;
|
2020-03-20 05:11:35 +08:00
|
|
|
}
|