2011-01-01 01:31:54 +08:00
|
|
|
//===--- ToolChains.cpp - ToolChain Implementations -----------------------===//
|
2009-03-20 08:20:03 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "ToolChains.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "SanitizerArgs.h"
|
|
|
|
#include "clang/Basic/ObjCRuntime.h"
|
|
|
|
#include "clang/Basic/Version.h"
|
2009-03-25 12:13:45 +08:00
|
|
|
#include "clang/Driver/Arg.h"
|
|
|
|
#include "clang/Driver/ArgList.h"
|
2010-05-21 05:48:38 +08:00
|
|
|
#include "clang/Driver/Compilation.h"
|
2009-03-24 00:15:50 +08:00
|
|
|
#include "clang/Driver/Driver.h"
|
2009-03-25 14:12:34 +08:00
|
|
|
#include "clang/Driver/DriverDiagnostic.h"
|
2009-11-19 08:15:11 +08:00
|
|
|
#include "clang/Driver/OptTable.h"
|
2009-03-25 14:12:34 +08:00
|
|
|
#include "clang/Driver/Option.h"
|
2009-11-19 12:25:22 +08:00
|
|
|
#include "clang/Driver/Options.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2010-08-24 06:35:37 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2009-03-24 00:15:50 +08:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2011-10-07 08:37:57 +08:00
|
|
|
#include "llvm/ADT/StringSwitch.h"
|
2009-09-10 06:33:15 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2011-01-10 10:34:13 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2010-11-08 04:14:31 +08:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2010-11-30 02:12:39 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2010-12-10 01:36:38 +08:00
|
|
|
#include "llvm/Support/system_error.h"
|
2012-12-04 22:31:59 +08:00
|
|
|
|
|
|
|
// FIXME: This needs to be listed last until we fix the broken include guards
|
|
|
|
// in these files and the LLVM config.h files.
|
|
|
|
#include "clang/Config/config.h" // for GCC_INSTALL_PREFIX
|
|
|
|
|
2009-04-11 05:00:07 +08:00
|
|
|
#include <cstdlib> // ::getenv
|
|
|
|
|
2009-03-20 08:20:03 +08:00
|
|
|
using namespace clang::driver;
|
|
|
|
using namespace clang::driver::toolchains;
|
2011-07-23 18:55:15 +08:00
|
|
|
using namespace clang;
|
2009-03-20 08:20:03 +08:00
|
|
|
|
2009-09-05 02:34:51 +08:00
|
|
|
/// Darwin - Darwin tool chain for i386 and x86_64.
|
2009-03-20 08:57:52 +08:00
|
|
|
|
2013-03-19 02:10:27 +08:00
|
|
|
Darwin::Darwin(const Driver &D, const llvm::Triple& Triple, const ArgList &Args)
|
|
|
|
: ToolChain(D, Triple, Args), TargetInitialized(false)
|
2009-09-18 16:15:13 +08:00
|
|
|
{
|
2012-02-01 05:30:03 +08:00
|
|
|
// Compute the initial Darwin version from the triple
|
|
|
|
unsigned Major, Minor, Micro;
|
2012-02-01 06:43:59 +08:00
|
|
|
if (!Triple.getMacOSXVersion(Major, Minor, Micro))
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_darwin_version) <<
|
|
|
|
Triple.getOSName();
|
|
|
|
llvm::raw_string_ostream(MacosxVersionMin)
|
|
|
|
<< Major << '.' << Minor << '.' << Micro;
|
|
|
|
|
2012-02-01 05:30:03 +08:00
|
|
|
// FIXME: DarwinVersion is only used to find GCC's libexec directory.
|
|
|
|
// It should be removed when we stop supporting that.
|
|
|
|
DarwinVersion[0] = Minor + 4;
|
|
|
|
DarwinVersion[1] = Micro;
|
|
|
|
DarwinVersion[2] = 0;
|
2012-05-10 02:46:30 +08:00
|
|
|
|
|
|
|
// Compute the initial iOS version from the triple
|
2012-05-10 02:51:13 +08:00
|
|
|
Triple.getiOSVersion(Major, Minor, Micro);
|
2012-05-10 02:46:30 +08:00
|
|
|
llvm::raw_string_ostream(iOSVersionMin)
|
|
|
|
<< Major << '.' << Minor << '.' << Micro;
|
2009-09-18 16:15:13 +08:00
|
|
|
}
|
|
|
|
|
2010-08-02 13:43:56 +08:00
|
|
|
types::ID Darwin::LookupTypeForExtension(const char *Ext) const {
|
|
|
|
types::ID Ty = types::lookupTypeForExtension(Ext);
|
|
|
|
|
|
|
|
// Darwin always preprocesses assembly files (unless -x is used explicitly).
|
|
|
|
if (Ty == types::TY_PP_Asm)
|
|
|
|
return types::TY_Asm;
|
|
|
|
|
|
|
|
return Ty;
|
|
|
|
}
|
|
|
|
|
2010-09-17 08:24:52 +08:00
|
|
|
bool Darwin::HasNativeLLVMSupport() const {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2011-07-06 08:26:06 +08:00
|
|
|
/// Darwin provides an ARC runtime starting in MacOS X 10.7 and iOS 5.0.
|
2012-06-20 14:18:46 +08:00
|
|
|
ObjCRuntime Darwin::getDefaultObjCRuntime(bool isNonFragile) const {
|
2012-11-09 09:59:30 +08:00
|
|
|
if (isTargetIPhoneOS())
|
2012-06-20 14:18:46 +08:00
|
|
|
return ObjCRuntime(ObjCRuntime::iOS, TargetVersion);
|
2012-11-09 09:59:30 +08:00
|
|
|
if (isNonFragile)
|
|
|
|
return ObjCRuntime(ObjCRuntime::MacOSX, TargetVersion);
|
|
|
|
return ObjCRuntime(ObjCRuntime::FragileMacOSX, TargetVersion);
|
2011-07-06 08:26:06 +08:00
|
|
|
}
|
|
|
|
|
2011-09-10 04:41:01 +08:00
|
|
|
/// Darwin provides a blocks runtime starting in MacOS X 10.6 and iOS 3.2.
|
|
|
|
bool Darwin::hasBlocksRuntime() const {
|
|
|
|
if (isTargetIPhoneOS())
|
|
|
|
return !isIPhoneOSVersionLT(3, 2);
|
|
|
|
else
|
|
|
|
return !isMacosxVersionLT(10, 6);
|
|
|
|
}
|
|
|
|
|
2011-07-23 18:55:15 +08:00
|
|
|
static const char *GetArmArchForMArch(StringRef Value) {
|
2011-10-07 08:37:57 +08:00
|
|
|
return llvm::StringSwitch<const char*>(Value)
|
|
|
|
.Case("armv6k", "armv6")
|
2013-03-05 06:37:49 +08:00
|
|
|
.Case("armv6m", "armv6m")
|
2011-10-07 08:37:57 +08:00
|
|
|
.Case("armv5tej", "armv5")
|
|
|
|
.Case("xscale", "xscale")
|
|
|
|
.Case("armv4t", "armv4t")
|
|
|
|
.Case("armv7", "armv7")
|
|
|
|
.Cases("armv7a", "armv7-a", "armv7")
|
|
|
|
.Cases("armv7r", "armv7-r", "armv7")
|
2013-03-05 06:37:49 +08:00
|
|
|
.Cases("armv7em", "armv7e-m", "armv7em")
|
2012-09-30 07:52:50 +08:00
|
|
|
.Cases("armv7f", "armv7-f", "armv7f")
|
|
|
|
.Cases("armv7k", "armv7-k", "armv7k")
|
2013-03-05 06:37:49 +08:00
|
|
|
.Cases("armv7m", "armv7-m", "armv7m")
|
2012-09-30 07:52:50 +08:00
|
|
|
.Cases("armv7s", "armv7-s", "armv7s")
|
2011-10-07 08:37:57 +08:00
|
|
|
.Default(0);
|
2010-01-22 10:04:58 +08:00
|
|
|
}
|
|
|
|
|
2011-07-23 18:55:15 +08:00
|
|
|
static const char *GetArmArchForMCpu(StringRef Value) {
|
2011-10-07 08:37:57 +08:00
|
|
|
return llvm::StringSwitch<const char *>(Value)
|
|
|
|
.Cases("arm9e", "arm946e-s", "arm966e-s", "arm968e-s", "arm926ej-s","armv5")
|
|
|
|
.Cases("arm10e", "arm10tdmi", "armv5")
|
|
|
|
.Cases("arm1020t", "arm1020e", "arm1022e", "arm1026ej-s", "armv5")
|
|
|
|
.Case("xscale", "xscale")
|
2013-03-05 06:37:49 +08:00
|
|
|
.Cases("arm1136j-s", "arm1136jf-s", "arm1176jz-s", "arm1176jzf-s", "armv6")
|
|
|
|
.Case("cortex-m0", "armv6m")
|
|
|
|
.Cases("cortex-a8", "cortex-r4", "cortex-a9", "cortex-a15", "armv7")
|
2012-09-30 07:52:50 +08:00
|
|
|
.Case("cortex-a9-mp", "armv7f")
|
2013-03-05 06:37:49 +08:00
|
|
|
.Case("cortex-m3", "armv7m")
|
|
|
|
.Case("cortex-m4", "armv7em")
|
2012-09-30 07:52:50 +08:00
|
|
|
.Case("swift", "armv7s")
|
2011-10-07 08:37:57 +08:00
|
|
|
.Default(0);
|
2010-01-22 10:04:58 +08:00
|
|
|
}
|
|
|
|
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef Darwin::getDarwinArchName(const ArgList &Args) const {
|
2010-01-22 10:04:58 +08:00
|
|
|
switch (getTriple().getArch()) {
|
|
|
|
default:
|
|
|
|
return getArchName();
|
2011-06-03 11:49:51 +08:00
|
|
|
|
2011-03-07 03:11:49 +08:00
|
|
|
case llvm::Triple::thumb:
|
2010-01-22 10:04:58 +08:00
|
|
|
case llvm::Triple::arm: {
|
|
|
|
if (const Arg *A = Args.getLastArg(options::OPT_march_EQ))
|
2012-11-01 12:30:05 +08:00
|
|
|
if (const char *Arch = GetArmArchForMArch(A->getValue()))
|
2010-01-22 10:04:58 +08:00
|
|
|
return Arch;
|
|
|
|
|
|
|
|
if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
|
2012-11-01 12:30:05 +08:00
|
|
|
if (const char *Arch = GetArmArchForMCpu(A->getValue()))
|
2010-01-22 10:04:58 +08:00
|
|
|
return Arch;
|
|
|
|
|
|
|
|
return "arm";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-09-05 02:34:51 +08:00
|
|
|
Darwin::~Darwin() {
|
2009-03-20 08:57:52 +08:00
|
|
|
}
|
|
|
|
|
2011-09-21 04:44:06 +08:00
|
|
|
std::string Darwin::ComputeEffectiveClangTriple(const ArgList &Args,
|
|
|
|
types::ID InputType) const {
|
|
|
|
llvm::Triple Triple(ComputeLLVMTriple(Args, InputType));
|
2010-08-24 06:35:37 +08:00
|
|
|
|
|
|
|
// If the target isn't initialized (e.g., an unknown Darwin platform, return
|
|
|
|
// the default triple).
|
|
|
|
if (!isTargetInitialized())
|
|
|
|
return Triple.getTriple();
|
2011-06-03 11:49:51 +08:00
|
|
|
|
2012-02-05 10:13:05 +08:00
|
|
|
SmallString<16> Str;
|
2012-03-11 04:55:36 +08:00
|
|
|
Str += isTargetIPhoneOS() ? "ios" : "macosx";
|
|
|
|
Str += getTargetVersion().getAsString();
|
|
|
|
Triple.setOSName(Str);
|
2010-08-24 06:35:37 +08:00
|
|
|
|
|
|
|
return Triple.getTriple();
|
|
|
|
}
|
|
|
|
|
2011-12-20 10:48:34 +08:00
|
|
|
void Generic_ELF::anchor() {}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Darwin::getTool(Action::ActionClass AC) const {
|
2013-03-19 04:48:54 +08:00
|
|
|
switch (AC) {
|
2013-03-19 02:50:01 +08:00
|
|
|
case Action::LipoJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
if (!Lipo)
|
|
|
|
Lipo.reset(new tools::darwin::Lipo(*this));
|
|
|
|
return Lipo.get();
|
2013-03-19 02:50:01 +08:00
|
|
|
case Action::DsymutilJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
if (!Dsymutil)
|
|
|
|
Dsymutil.reset(new tools::darwin::Dsymutil(*this));
|
|
|
|
return Dsymutil.get();
|
2013-03-19 02:50:01 +08:00
|
|
|
case Action::VerifyJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
if (!VerifyDebug)
|
|
|
|
VerifyDebug.reset(new tools::darwin::VerifyDebug(*this));
|
|
|
|
return VerifyDebug.get();
|
2013-03-19 08:36:57 +08:00
|
|
|
default:
|
2013-03-20 11:05:54 +08:00
|
|
|
return ToolChain::getTool(AC);
|
2009-03-20 08:57:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Darwin::buildLinker() const {
|
|
|
|
return new tools::darwin::Link(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Darwin::buildAssembler() const {
|
|
|
|
return new tools::darwin::Assemble(*this);
|
|
|
|
}
|
2009-09-18 16:15:03 +08:00
|
|
|
|
2013-03-19 02:10:27 +08:00
|
|
|
DarwinClang::DarwinClang(const Driver &D, const llvm::Triple& Triple,
|
|
|
|
const ArgList &Args)
|
|
|
|
: Darwin(D, Triple, Args)
|
2009-09-18 16:15:13 +08:00
|
|
|
{
|
2010-09-17 16:22:12 +08:00
|
|
|
getProgramPaths().push_back(getDriver().getInstalledDir());
|
|
|
|
if (getDriver().getInstalledDir() != getDriver().Dir)
|
|
|
|
getProgramPaths().push_back(getDriver().Dir);
|
|
|
|
|
2009-09-18 16:15:13 +08:00
|
|
|
// We expect 'as', 'ld', etc. to be adjacent to our install dir.
|
2010-08-02 06:29:51 +08:00
|
|
|
getProgramPaths().push_back(getDriver().getInstalledDir());
|
|
|
|
if (getDriver().getInstalledDir() != getDriver().Dir)
|
|
|
|
getProgramPaths().push_back(getDriver().Dir);
|
2009-09-18 16:15:13 +08:00
|
|
|
}
|
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
void DarwinClang::AddLinkARCArgs(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
2011-08-24 01:56:55 +08:00
|
|
|
|
|
|
|
CmdArgs.push_back("-force_load");
|
2011-06-16 07:02:42 +08:00
|
|
|
llvm::sys::Path P(getDriver().ClangExecutable);
|
|
|
|
P.eraseComponent(); // 'clang'
|
|
|
|
P.eraseComponent(); // 'bin'
|
|
|
|
P.appendComponent("lib");
|
|
|
|
P.appendComponent("arc");
|
|
|
|
P.appendComponent("libarclite_");
|
|
|
|
std::string s = P.str();
|
|
|
|
// Mash in the platform.
|
2011-10-19 01:40:15 +08:00
|
|
|
if (isTargetIOSSimulator())
|
|
|
|
s += "iphonesimulator";
|
|
|
|
else if (isTargetIPhoneOS())
|
2011-06-16 07:02:42 +08:00
|
|
|
s += "iphoneos";
|
|
|
|
else
|
|
|
|
s += "macosx";
|
|
|
|
s += ".a";
|
|
|
|
|
|
|
|
CmdArgs.push_back(Args.MakeArgString(s));
|
|
|
|
}
|
|
|
|
|
2011-06-23 01:41:40 +08:00
|
|
|
void DarwinClang::AddLinkRuntimeLib(const ArgList &Args,
|
2011-08-24 01:56:55 +08:00
|
|
|
ArgStringList &CmdArgs,
|
2012-11-21 22:17:42 +08:00
|
|
|
const char *DarwinStaticLib,
|
|
|
|
bool AlwaysLink) const {
|
2011-06-23 01:41:40 +08:00
|
|
|
llvm::sys::Path P(getDriver().ResourceDir);
|
|
|
|
P.appendComponent("lib");
|
|
|
|
P.appendComponent("darwin");
|
|
|
|
P.appendComponent(DarwinStaticLib);
|
2011-08-24 01:56:55 +08:00
|
|
|
|
2011-06-23 01:41:40 +08:00
|
|
|
// For now, allow missing resource libraries to support developers who may
|
2012-11-21 22:17:42 +08:00
|
|
|
// not have compiler-rt checked out or integrated into their build (unless
|
|
|
|
// we explicitly force linking with this library).
|
2011-06-23 01:41:40 +08:00
|
|
|
bool Exists;
|
2012-11-21 22:17:42 +08:00
|
|
|
if (AlwaysLink || (!llvm::sys::fs::exists(P.str(), Exists) && Exists))
|
2011-06-23 01:41:40 +08:00
|
|
|
CmdArgs.push_back(Args.MakeArgString(P.str()));
|
|
|
|
}
|
|
|
|
|
2009-09-18 16:15:13 +08:00
|
|
|
void DarwinClang::AddLinkRuntimeLibArgs(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
2011-12-08 07:03:15 +08:00
|
|
|
// Darwin only supports the compiler-rt based runtime libraries.
|
|
|
|
switch (GetRuntimeLibType(Args)) {
|
|
|
|
case ToolChain::RLT_CompilerRT:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
getDriver().Diag(diag::err_drv_unsupported_rtlib_for_platform)
|
2012-11-01 12:30:05 +08:00
|
|
|
<< Args.getLastArg(options::OPT_rtlib_EQ)->getValue() << "darwin";
|
2011-12-08 07:03:15 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-01-22 11:38:14 +08:00
|
|
|
// Darwin doesn't support real static executables, don't link any runtime
|
|
|
|
// libraries with -static.
|
2012-10-16 06:23:53 +08:00
|
|
|
if (Args.hasArg(options::OPT_static) ||
|
|
|
|
Args.hasArg(options::OPT_fapple_kext) ||
|
|
|
|
Args.hasArg(options::OPT_mkernel))
|
2009-09-18 16:15:13 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
// Reject -static-libgcc for now, we can deal with this when and if someone
|
|
|
|
// cares. This is useful in situations where someone wants to statically link
|
|
|
|
// something like libstdc++, and needs its runtime support routines.
|
|
|
|
if (const Arg *A = Args.getLastArg(options::OPT_static_libgcc)) {
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_unsupported_opt)
|
2009-09-18 16:15:13 +08:00
|
|
|
<< A->getAsString(Args);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-11-17 08:36:57 +08:00
|
|
|
// If we are building profile support, link that library in.
|
|
|
|
if (Args.hasArg(options::OPT_fprofile_arcs) ||
|
|
|
|
Args.hasArg(options::OPT_fprofile_generate) ||
|
|
|
|
Args.hasArg(options::OPT_fcreate_profile) ||
|
|
|
|
Args.hasArg(options::OPT_coverage)) {
|
|
|
|
// Select the appropriate runtime library for the target.
|
|
|
|
if (isTargetIPhoneOS()) {
|
|
|
|
AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.profile_ios.a");
|
|
|
|
} else {
|
|
|
|
AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.profile_osx.a");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-09 12:35:11 +08:00
|
|
|
SanitizerArgs Sanitize(*this, Args);
|
2012-11-06 23:09:03 +08:00
|
|
|
|
2012-11-16 20:53:14 +08:00
|
|
|
// Add Ubsan runtime library, if required.
|
|
|
|
if (Sanitize.needsUbsanRt()) {
|
2013-01-21 16:45:02 +08:00
|
|
|
if (isTargetIPhoneOS()) {
|
2012-11-16 20:53:14 +08:00
|
|
|
getDriver().Diag(diag::err_drv_clang_unsupported_per_platform)
|
|
|
|
<< "-fsanitize=undefined";
|
|
|
|
} else {
|
2012-11-21 22:17:42 +08:00
|
|
|
AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.ubsan_osx.a", true);
|
2012-11-16 20:53:14 +08:00
|
|
|
|
|
|
|
// The Ubsan runtime library requires C++.
|
|
|
|
AddCXXStdlibLibArgs(Args, CmdArgs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-07 03:18:44 +08:00
|
|
|
// Add ASAN runtime library, if required. Dynamic libraries and bundles
|
|
|
|
// should not be linked with the runtime library.
|
2012-11-06 23:09:03 +08:00
|
|
|
if (Sanitize.needsAsanRt()) {
|
2013-03-21 18:49:06 +08:00
|
|
|
if (isTargetIPhoneOS() && !isTargetIOSSimulator()) {
|
2011-12-02 07:40:18 +08:00
|
|
|
getDriver().Diag(diag::err_drv_clang_unsupported_per_platform)
|
2012-11-06 23:09:03 +08:00
|
|
|
<< "-fsanitize=address";
|
2011-12-02 07:40:18 +08:00
|
|
|
} else {
|
2013-03-21 18:49:06 +08:00
|
|
|
if (Args.hasArg(options::OPT_dynamiclib) ||
|
|
|
|
Args.hasArg(options::OPT_bundle)) {
|
|
|
|
// Assume the binary will provide the ASan runtime.
|
|
|
|
} else {
|
|
|
|
AddLinkRuntimeLib(Args, CmdArgs,
|
|
|
|
"libclang_rt.asan_osx_dynamic.dylib", true);
|
|
|
|
// The ASAN runtime library requires C++.
|
|
|
|
AddCXXStdlibLibArgs(Args, CmdArgs);
|
|
|
|
}
|
2011-12-02 07:40:18 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-22 11:38:14 +08:00
|
|
|
// Otherwise link libSystem, then the dynamic runtime library, and finally any
|
|
|
|
// target specific static runtime library.
|
2009-09-18 16:15:13 +08:00
|
|
|
CmdArgs.push_back("-lSystem");
|
2010-01-22 11:38:14 +08:00
|
|
|
|
|
|
|
// Select the dynamic runtime library and the target specific static library.
|
2010-01-27 08:56:37 +08:00
|
|
|
if (isTargetIPhoneOS()) {
|
2011-04-30 12:25:16 +08:00
|
|
|
// If we are compiling as iOS / simulator, don't attempt to link libgcc_s.1,
|
|
|
|
// it never went into the SDK.
|
2011-10-08 01:54:41 +08:00
|
|
|
// Linking against libgcc_s.1 isn't needed for iOS 5.0+
|
|
|
|
if (isIPhoneOSVersionLT(5, 0) && !isTargetIOSSimulator())
|
|
|
|
CmdArgs.push_back("-lgcc_s.1");
|
2010-01-22 11:38:14 +08:00
|
|
|
|
2011-04-19 07:48:36 +08:00
|
|
|
// We currently always need a static runtime library for iOS.
|
2011-06-23 01:41:40 +08:00
|
|
|
AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.ios.a");
|
2010-01-22 11:38:14 +08:00
|
|
|
} else {
|
|
|
|
// The dynamic runtime library was merged with libSystem for 10.6 and
|
|
|
|
// beyond; only 10.4 and 10.5 need an additional runtime library.
|
2010-01-27 08:57:03 +08:00
|
|
|
if (isMacosxVersionLT(10, 5))
|
2010-01-22 11:38:14 +08:00
|
|
|
CmdArgs.push_back("-lgcc_s.10.4");
|
2010-01-27 08:57:03 +08:00
|
|
|
else if (isMacosxVersionLT(10, 6))
|
2010-01-22 11:38:14 +08:00
|
|
|
CmdArgs.push_back("-lgcc_s.10.5");
|
|
|
|
|
2010-09-22 08:03:52 +08:00
|
|
|
// For OS X, we thought we would only need a static runtime library when
|
2011-04-15 13:22:18 +08:00
|
|
|
// targeting 10.4, to provide versions of the static functions which were
|
2010-09-22 08:03:52 +08:00
|
|
|
// omitted from 10.4.dylib.
|
|
|
|
//
|
|
|
|
// Unfortunately, that turned out to not be true, because Darwin system
|
|
|
|
// headers can still use eprintf on i386, and it is not exported from
|
|
|
|
// libSystem. Therefore, we still must provide a runtime library just for
|
|
|
|
// the tiny tiny handful of projects that *might* use that symbol.
|
|
|
|
if (isMacosxVersionLT(10, 5)) {
|
2011-06-23 01:41:40 +08:00
|
|
|
AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.10.4.a");
|
2010-09-22 08:03:52 +08:00
|
|
|
} else {
|
|
|
|
if (getTriple().getArch() == llvm::Triple::x86)
|
2011-06-23 01:41:40 +08:00
|
|
|
AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.eprintf.a");
|
|
|
|
AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.osx.a");
|
2010-09-22 08:03:52 +08:00
|
|
|
}
|
2010-01-22 11:38:14 +08:00
|
|
|
}
|
2009-09-18 16:15:13 +08:00
|
|
|
}
|
|
|
|
|
2010-07-20 01:11:36 +08:00
|
|
|
void Darwin::AddDeploymentTarget(DerivedArgList &Args) const {
|
2009-12-22 02:54:17 +08:00
|
|
|
const OptTable &Opts = getDriver().getOpts();
|
2009-03-25 14:58:31 +08:00
|
|
|
|
2012-08-18 02:43:50 +08:00
|
|
|
// Support allowing the SDKROOT environment variable used by xcrun and other
|
|
|
|
// Xcode tools to define the default sysroot, by making it the default for
|
|
|
|
// isysroot.
|
2012-12-20 07:41:50 +08:00
|
|
|
if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
|
|
|
|
// Warn if the path does not exist.
|
|
|
|
bool Exists;
|
|
|
|
if (llvm::sys::fs::exists(A->getValue(), Exists) || !Exists)
|
|
|
|
getDriver().Diag(clang::diag::warn_missing_sysroot) << A->getValue();
|
|
|
|
} else {
|
2012-08-18 02:43:50 +08:00
|
|
|
if (char *env = ::getenv("SDKROOT")) {
|
2013-01-16 04:33:56 +08:00
|
|
|
// We only use this value as the default if it is an absolute path,
|
|
|
|
// exists, and it is not the root path.
|
|
|
|
if (llvm::sys::path::is_absolute(env) && llvm::sys::fs::exists(env) &&
|
|
|
|
StringRef(env) != "/") {
|
2012-08-18 02:43:50 +08:00
|
|
|
Args.append(Args.MakeSeparateArg(
|
|
|
|
0, Opts.getOption(options::OPT_isysroot), env));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-27 08:56:25 +08:00
|
|
|
Arg *OSXVersion = Args.getLastArg(options::OPT_mmacosx_version_min_EQ);
|
2011-04-30 12:15:58 +08:00
|
|
|
Arg *iOSVersion = Args.getLastArg(options::OPT_miphoneos_version_min_EQ);
|
|
|
|
Arg *iOSSimVersion = Args.getLastArg(
|
|
|
|
options::OPT_mios_simulator_version_min_EQ);
|
2012-01-11 10:41:15 +08:00
|
|
|
|
2011-04-30 12:15:58 +08:00
|
|
|
if (OSXVersion && (iOSVersion || iOSSimVersion)) {
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_argument_not_allowed_with)
|
2009-04-11 04:11:50 +08:00
|
|
|
<< OSXVersion->getAsString(Args)
|
2011-04-30 12:15:58 +08:00
|
|
|
<< (iOSVersion ? iOSVersion : iOSSimVersion)->getAsString(Args);
|
|
|
|
iOSVersion = iOSSimVersion = 0;
|
|
|
|
} else if (iOSVersion && iOSSimVersion) {
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_argument_not_allowed_with)
|
2011-04-30 12:15:58 +08:00
|
|
|
<< iOSVersion->getAsString(Args)
|
|
|
|
<< iOSSimVersion->getAsString(Args);
|
|
|
|
iOSSimVersion = 0;
|
|
|
|
} else if (!OSXVersion && !iOSVersion && !iOSSimVersion) {
|
2011-09-01 04:56:25 +08:00
|
|
|
// If no deployment target was specified on the command line, check for
|
2010-01-26 09:45:19 +08:00
|
|
|
// environment defines.
|
2011-09-01 04:56:25 +08:00
|
|
|
StringRef OSXTarget;
|
|
|
|
StringRef iOSTarget;
|
|
|
|
StringRef iOSSimTarget;
|
|
|
|
if (char *env = ::getenv("MACOSX_DEPLOYMENT_TARGET"))
|
|
|
|
OSXTarget = env;
|
|
|
|
if (char *env = ::getenv("IPHONEOS_DEPLOYMENT_TARGET"))
|
|
|
|
iOSTarget = env;
|
|
|
|
if (char *env = ::getenv("IOS_SIMULATOR_DEPLOYMENT_TARGET"))
|
|
|
|
iOSSimTarget = env;
|
|
|
|
|
2011-10-08 19:31:46 +08:00
|
|
|
// If no '-miphoneos-version-min' specified on the command line and
|
2011-09-01 04:56:25 +08:00
|
|
|
// IPHONEOS_DEPLOYMENT_TARGET is not defined, see if we can set the default
|
2012-04-18 18:59:08 +08:00
|
|
|
// based on -isysroot.
|
2011-09-01 04:56:25 +08:00
|
|
|
if (iOSTarget.empty()) {
|
|
|
|
if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
|
|
|
|
StringRef first, second;
|
2012-11-01 12:30:05 +08:00
|
|
|
StringRef isysroot = A->getValue();
|
2011-09-01 04:56:25 +08:00
|
|
|
llvm::tie(first, second) = isysroot.split(StringRef("SDKs/iPhoneOS"));
|
|
|
|
if (second != "")
|
|
|
|
iOSTarget = second.substr(0,3);
|
|
|
|
}
|
|
|
|
}
|
2010-01-26 09:45:19 +08:00
|
|
|
|
2011-09-28 08:46:32 +08:00
|
|
|
// If no OSX or iOS target has been specified and we're compiling for armv7,
|
|
|
|
// go ahead as assume we're targeting iOS.
|
2012-05-10 02:55:57 +08:00
|
|
|
if (OSXTarget.empty() && iOSTarget.empty() &&
|
2012-09-30 07:52:50 +08:00
|
|
|
(getDarwinArchName(Args) == "armv7" ||
|
|
|
|
getDarwinArchName(Args) == "armv7s"))
|
2012-05-10 02:09:58 +08:00
|
|
|
iOSTarget = iOSVersionMin;
|
2011-09-28 08:46:32 +08:00
|
|
|
|
2011-04-30 12:15:58 +08:00
|
|
|
// Handle conflicting deployment targets
|
2010-02-03 01:31:12 +08:00
|
|
|
//
|
|
|
|
// FIXME: Don't hardcode default here.
|
2011-04-30 12:15:58 +08:00
|
|
|
|
|
|
|
// Do not allow conflicts with the iOS simulator target.
|
2011-09-01 04:56:25 +08:00
|
|
|
if (!iOSSimTarget.empty() && (!OSXTarget.empty() || !iOSTarget.empty())) {
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_conflicting_deployment_targets)
|
2011-04-30 12:15:58 +08:00
|
|
|
<< "IOS_SIMULATOR_DEPLOYMENT_TARGET"
|
2011-09-01 04:56:25 +08:00
|
|
|
<< (!OSXTarget.empty() ? "MACOSX_DEPLOYMENT_TARGET" :
|
2011-04-30 12:15:58 +08:00
|
|
|
"IPHONEOS_DEPLOYMENT_TARGET");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Allow conflicts among OSX and iOS for historical reasons, but choose the
|
|
|
|
// default platform.
|
2011-09-01 04:56:25 +08:00
|
|
|
if (!OSXTarget.empty() && !iOSTarget.empty()) {
|
2010-02-03 01:31:12 +08:00
|
|
|
if (getTriple().getArch() == llvm::Triple::arm ||
|
|
|
|
getTriple().getArch() == llvm::Triple::thumb)
|
2011-09-01 04:56:25 +08:00
|
|
|
OSXTarget = "";
|
2010-02-03 01:31:12 +08:00
|
|
|
else
|
2011-09-01 04:56:25 +08:00
|
|
|
iOSTarget = "";
|
2010-02-03 01:31:12 +08:00
|
|
|
}
|
2010-01-30 01:02:25 +08:00
|
|
|
|
2011-09-01 04:56:25 +08:00
|
|
|
if (!OSXTarget.empty()) {
|
2012-10-20 06:36:40 +08:00
|
|
|
const Option O = Opts.getOption(options::OPT_mmacosx_version_min_EQ);
|
2010-07-20 01:11:36 +08:00
|
|
|
OSXVersion = Args.MakeJoinedArg(0, O, OSXTarget);
|
|
|
|
Args.append(OSXVersion);
|
2011-09-01 04:56:25 +08:00
|
|
|
} else if (!iOSTarget.empty()) {
|
2012-10-20 06:36:40 +08:00
|
|
|
const Option O = Opts.getOption(options::OPT_miphoneos_version_min_EQ);
|
2011-04-30 12:15:58 +08:00
|
|
|
iOSVersion = Args.MakeJoinedArg(0, O, iOSTarget);
|
|
|
|
Args.append(iOSVersion);
|
2011-09-01 04:56:25 +08:00
|
|
|
} else if (!iOSSimTarget.empty()) {
|
2012-10-20 06:36:40 +08:00
|
|
|
const Option O = Opts.getOption(
|
2011-04-30 12:15:58 +08:00
|
|
|
options::OPT_mios_simulator_version_min_EQ);
|
|
|
|
iOSSimVersion = Args.MakeJoinedArg(0, O, iOSSimTarget);
|
|
|
|
Args.append(iOSSimVersion);
|
2010-01-26 09:45:19 +08:00
|
|
|
} else {
|
2010-07-16 00:18:06 +08:00
|
|
|
// Otherwise, assume we are targeting OS X.
|
2012-10-20 06:36:40 +08:00
|
|
|
const Option O = Opts.getOption(options::OPT_mmacosx_version_min_EQ);
|
2010-07-20 01:11:36 +08:00
|
|
|
OSXVersion = Args.MakeJoinedArg(0, O, MacosxVersionMin);
|
|
|
|
Args.append(OSXVersion);
|
2009-09-05 02:35:21 +08:00
|
|
|
}
|
2009-03-25 14:58:31 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-04-30 12:20:40 +08:00
|
|
|
// Reject invalid architecture combinations.
|
|
|
|
if (iOSSimVersion && (getTriple().getArch() != llvm::Triple::x86 &&
|
|
|
|
getTriple().getArch() != llvm::Triple::x86_64)) {
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_invalid_arch_for_deployment_target)
|
2011-04-30 12:20:40 +08:00
|
|
|
<< getTriple().getArchName() << iOSSimVersion->getAsString(Args);
|
|
|
|
}
|
|
|
|
|
2010-01-27 08:56:25 +08:00
|
|
|
// Set the tool chain target information.
|
|
|
|
unsigned Major, Minor, Micro;
|
|
|
|
bool HadExtra;
|
|
|
|
if (OSXVersion) {
|
2011-04-30 12:15:58 +08:00
|
|
|
assert((!iOSVersion && !iOSSimVersion) && "Unknown target platform!");
|
2012-11-01 12:30:05 +08:00
|
|
|
if (!Driver::GetReleaseVersion(OSXVersion->getValue(), Major, Minor,
|
2010-01-27 08:56:25 +08:00
|
|
|
Micro, HadExtra) || HadExtra ||
|
2011-04-22 05:27:33 +08:00
|
|
|
Major != 10 || Minor >= 100 || Micro >= 100)
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_invalid_version_number)
|
2010-01-27 08:56:25 +08:00
|
|
|
<< OSXVersion->getAsString(Args);
|
|
|
|
} else {
|
2011-04-30 12:15:58 +08:00
|
|
|
const Arg *Version = iOSVersion ? iOSVersion : iOSSimVersion;
|
|
|
|
assert(Version && "Unknown target platform!");
|
2012-11-01 12:30:05 +08:00
|
|
|
if (!Driver::GetReleaseVersion(Version->getValue(), Major, Minor,
|
2012-01-11 10:41:15 +08:00
|
|
|
Micro, HadExtra) || HadExtra ||
|
|
|
|
Major >= 10 || Minor >= 100 || Micro >= 100)
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_version_number)
|
|
|
|
<< Version->getAsString(Args);
|
2010-01-27 08:56:25 +08:00
|
|
|
}
|
2011-04-30 12:15:58 +08:00
|
|
|
|
2011-04-30 12:18:16 +08:00
|
|
|
bool IsIOSSim = bool(iOSSimVersion);
|
|
|
|
|
|
|
|
// In GCC, the simulator historically was treated as being OS X in some
|
|
|
|
// contexts, like determining the link logic, despite generally being called
|
|
|
|
// with an iOS deployment target. For compatibility, we detect the
|
|
|
|
// simulator as iOS + x86, and treat it differently in a few contexts.
|
|
|
|
if (iOSVersion && (getTriple().getArch() == llvm::Triple::x86 ||
|
|
|
|
getTriple().getArch() == llvm::Triple::x86_64))
|
|
|
|
IsIOSSim = true;
|
|
|
|
|
|
|
|
setTarget(/*IsIPhoneOS=*/ !OSXVersion, Major, Minor, Micro, IsIOSSim);
|
2010-07-20 01:11:33 +08:00
|
|
|
}
|
|
|
|
|
2010-09-17 09:20:05 +08:00
|
|
|
void DarwinClang::AddCXXStdlibLibArgs(const ArgList &Args,
|
2010-09-17 09:16:06 +08:00
|
|
|
ArgStringList &CmdArgs) const {
|
|
|
|
CXXStdlibType Type = GetCXXStdlibType(Args);
|
|
|
|
|
|
|
|
switch (Type) {
|
|
|
|
case ToolChain::CST_Libcxx:
|
|
|
|
CmdArgs.push_back("-lc++");
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ToolChain::CST_Libstdcxx: {
|
|
|
|
// Unfortunately, -lstdc++ doesn't always exist in the standard search path;
|
|
|
|
// it was previously found in the gcc lib dir. However, for all the Darwin
|
|
|
|
// platforms we care about it was -lstdc++.6, so we search for that
|
|
|
|
// explicitly if we can't see an obvious -lstdc++ candidate.
|
|
|
|
|
|
|
|
// Check in the sysroot first.
|
2011-01-10 10:34:13 +08:00
|
|
|
bool Exists;
|
2010-09-17 09:16:06 +08:00
|
|
|
if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
|
2012-11-01 12:30:05 +08:00
|
|
|
llvm::sys::Path P(A->getValue());
|
2010-09-17 09:16:06 +08:00
|
|
|
P.appendComponent("usr");
|
|
|
|
P.appendComponent("lib");
|
|
|
|
P.appendComponent("libstdc++.dylib");
|
|
|
|
|
2011-01-10 10:34:13 +08:00
|
|
|
if (llvm::sys::fs::exists(P.str(), Exists) || !Exists) {
|
2010-09-17 09:16:06 +08:00
|
|
|
P.eraseComponent();
|
|
|
|
P.appendComponent("libstdc++.6.dylib");
|
2011-01-10 10:34:13 +08:00
|
|
|
if (!llvm::sys::fs::exists(P.str(), Exists) && Exists) {
|
2010-09-17 09:16:06 +08:00
|
|
|
CmdArgs.push_back(Args.MakeArgString(P.str()));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, look in the root.
|
2011-11-11 15:47:04 +08:00
|
|
|
// FIXME: This should be removed someday when we don't have to care about
|
|
|
|
// 10.6 and earlier, where /usr/lib/libstdc++.dylib does not exist.
|
2011-01-10 10:34:13 +08:00
|
|
|
if ((llvm::sys::fs::exists("/usr/lib/libstdc++.dylib", Exists) || !Exists)&&
|
|
|
|
(!llvm::sys::fs::exists("/usr/lib/libstdc++.6.dylib", Exists) && Exists)){
|
2010-09-17 09:16:06 +08:00
|
|
|
CmdArgs.push_back("/usr/lib/libstdc++.6.dylib");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, let the linker search.
|
|
|
|
CmdArgs.push_back("-lstdc++");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-09-18 02:39:08 +08:00
|
|
|
void DarwinClang::AddCCKextLibArgs(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
|
|
|
|
|
|
|
// For Darwin platforms, use the compiler-rt-based support library
|
|
|
|
// instead of the gcc-provided one (which is also incidentally
|
|
|
|
// only present in the gcc lib dir, which makes it hard to find).
|
|
|
|
|
|
|
|
llvm::sys::Path P(getDriver().ResourceDir);
|
|
|
|
P.appendComponent("lib");
|
|
|
|
P.appendComponent("darwin");
|
2012-10-16 06:23:53 +08:00
|
|
|
|
|
|
|
// Use the newer cc_kext for iOS ARM after 6.0.
|
|
|
|
if (!isTargetIPhoneOS() || isTargetIOSSimulator() ||
|
|
|
|
!isIPhoneOSVersionLT(6, 0)) {
|
|
|
|
P.appendComponent("libclang_rt.cc_kext.a");
|
|
|
|
} else {
|
|
|
|
P.appendComponent("libclang_rt.cc_kext_ios5.a");
|
|
|
|
}
|
2011-06-03 11:49:51 +08:00
|
|
|
|
2010-09-18 02:39:08 +08:00
|
|
|
// For now, allow missing resource libraries to support developers who may
|
|
|
|
// not have compiler-rt checked out or integrated into their build.
|
2011-01-10 10:34:13 +08:00
|
|
|
bool Exists;
|
|
|
|
if (!llvm::sys::fs::exists(P.str(), Exists) && Exists)
|
2010-09-18 02:39:08 +08:00
|
|
|
CmdArgs.push_back(Args.MakeArgString(P.str()));
|
|
|
|
}
|
|
|
|
|
2010-07-20 01:11:33 +08:00
|
|
|
DerivedArgList *Darwin::TranslateArgs(const DerivedArgList &Args,
|
|
|
|
const char *BoundArch) const {
|
|
|
|
DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
|
|
|
|
const OptTable &Opts = getDriver().getOpts();
|
|
|
|
|
|
|
|
// FIXME: We really want to get out of the tool chain level argument
|
|
|
|
// translation business, as it makes the driver functionality much
|
|
|
|
// more opaque. For now, we follow gcc closely solely for the
|
|
|
|
// purpose of easily achieving feature parity & testability. Once we
|
|
|
|
// have something that works, we should reevaluate each translation
|
|
|
|
// and try to push it down into tool specific logic.
|
2010-01-27 08:56:25 +08:00
|
|
|
|
2010-06-12 06:00:26 +08:00
|
|
|
for (ArgList::const_iterator it = Args.begin(),
|
|
|
|
ie = Args.end(); it != ie; ++it) {
|
2009-03-25 14:12:34 +08:00
|
|
|
Arg *A = *it;
|
|
|
|
|
|
|
|
if (A->getOption().matches(options::OPT_Xarch__)) {
|
2011-06-21 08:20:17 +08:00
|
|
|
// Skip this argument unless the architecture matches either the toolchain
|
|
|
|
// triple arch, or the arch being bound.
|
2012-10-07 12:44:33 +08:00
|
|
|
llvm::Triple::ArchType XarchArch =
|
2012-11-01 12:30:05 +08:00
|
|
|
tools::darwin::getArchTypeForDarwinArchName(A->getValue(0));
|
2012-10-07 12:44:33 +08:00
|
|
|
if (!(XarchArch == getArch() ||
|
|
|
|
(BoundArch && XarchArch ==
|
2012-11-01 02:51:07 +08:00
|
|
|
tools::darwin::getArchTypeForDarwinArchName(BoundArch))))
|
2009-03-25 14:12:34 +08:00
|
|
|
continue;
|
|
|
|
|
2011-02-19 13:33:51 +08:00
|
|
|
Arg *OriginalArg = A;
|
2012-11-01 12:30:05 +08:00
|
|
|
unsigned Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
|
2010-06-15 05:23:08 +08:00
|
|
|
unsigned Prev = Index;
|
2009-03-25 14:58:31 +08:00
|
|
|
Arg *XarchArg = Opts.ParseOneArg(Args, Index);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-25 14:12:34 +08:00
|
|
|
// 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
|
|
|
|
// use isDriverOption() as an approximation, although things
|
|
|
|
// like -O4 are going to slip through.
|
2011-04-22 01:41:34 +08:00
|
|
|
if (!XarchArg || Index > Prev + 1) {
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_invalid_Xarch_argument_with_args)
|
2011-04-22 01:32:21 +08:00
|
|
|
<< A->getAsString(Args);
|
|
|
|
continue;
|
2012-10-20 06:37:06 +08:00
|
|
|
} else if (XarchArg->getOption().hasFlag(options::DriverOption)) {
|
2011-07-23 18:55:15 +08:00
|
|
|
getDriver().Diag(diag::err_drv_invalid_Xarch_argument_isdriver)
|
2009-03-25 14:12:34 +08:00
|
|
|
<< A->getAsString(Args);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2009-03-30 06:29:05 +08:00
|
|
|
XarchArg->setBaseArg(A);
|
2009-03-25 14:12:34 +08:00
|
|
|
A = XarchArg;
|
2010-06-15 05:23:08 +08:00
|
|
|
|
|
|
|
DAL->AddSynthesizedArg(A);
|
2011-02-19 13:33:51 +08:00
|
|
|
|
|
|
|
// Linker input arguments require custom handling. The problem is that we
|
|
|
|
// have already constructed the phase actions, so we can not treat them as
|
|
|
|
// "input arguments".
|
2012-10-20 06:37:06 +08:00
|
|
|
if (A->getOption().hasFlag(options::LinkerInput)) {
|
2011-02-19 13:33:51 +08:00
|
|
|
// Convert the argument into individual Zlinker_input_args.
|
|
|
|
for (unsigned i = 0, e = A->getNumValues(); i != e; ++i) {
|
|
|
|
DAL->AddSeparateArg(OriginalArg,
|
|
|
|
Opts.getOption(options::OPT_Zlinker_input),
|
2012-11-01 12:30:05 +08:00
|
|
|
A->getValue(i));
|
2011-06-03 11:49:51 +08:00
|
|
|
|
2011-02-19 13:33:51 +08:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
}
|
2009-03-25 14:12:34 +08:00
|
|
|
|
2009-03-25 14:58:31 +08:00
|
|
|
// Sob. These is strictly gcc compatible for the time being. Apple
|
|
|
|
// gcc translates options twice, which means that self-expanding
|
|
|
|
// options add duplicates.
|
2009-11-19 12:14:53 +08:00
|
|
|
switch ((options::ID) A->getOption().getID()) {
|
2009-03-25 14:58:31 +08:00
|
|
|
default:
|
|
|
|
DAL->append(A);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_mkernel:
|
|
|
|
case options::OPT_fapple_kext:
|
|
|
|
DAL->append(A);
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_static));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-25 14:58:31 +08:00
|
|
|
case options::OPT_dependency_file:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddSeparateArg(A, Opts.getOption(options::OPT_MF),
|
2012-11-01 12:30:05 +08:00
|
|
|
A->getValue());
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_gfull:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_g_Flag));
|
|
|
|
DAL->AddFlagArg(A,
|
|
|
|
Opts.getOption(options::OPT_fno_eliminate_unused_debug_symbols));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_gused:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_g_Flag));
|
|
|
|
DAL->AddFlagArg(A,
|
|
|
|
Opts.getOption(options::OPT_feliminate_unused_debug_symbols));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_shared:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_dynamiclib));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_fconstant_cfstrings:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_mconstant_cfstrings));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_fno_constant_cfstrings:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_mno_constant_cfstrings));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_Wnonportable_cfstrings:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A,
|
|
|
|
Opts.getOption(options::OPT_mwarn_nonportable_cfstrings));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_Wno_nonportable_cfstrings:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A,
|
|
|
|
Opts.getOption(options::OPT_mno_warn_nonportable_cfstrings));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_fpascal_strings:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_mpascal_strings));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case options::OPT_fno_pascal_strings:
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(A, Opts.getOption(options::OPT_mno_pascal_strings));
|
2009-03-25 14:58:31 +08:00
|
|
|
break;
|
|
|
|
}
|
2009-03-25 14:12:34 +08:00
|
|
|
}
|
|
|
|
|
2009-09-10 06:33:15 +08:00
|
|
|
if (getTriple().getArch() == llvm::Triple::x86 ||
|
|
|
|
getTriple().getArch() == llvm::Triple::x86_64)
|
2009-11-19 12:00:53 +08:00
|
|
|
if (!Args.hasArgNoClaim(options::OPT_mtune_EQ))
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, Opts.getOption(options::OPT_mtune_EQ), "core2");
|
2009-09-10 06:33:15 +08:00
|
|
|
|
|
|
|
// Add the arch options based on the particular spelling of -arch, to match
|
2012-04-27 22:58:16 +08:00
|
|
|
// how the driver driver works.
|
2009-09-10 06:33:15 +08:00
|
|
|
if (BoundArch) {
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef Name = BoundArch;
|
2012-10-20 06:36:40 +08:00
|
|
|
const Option MCpu = Opts.getOption(options::OPT_mcpu_EQ);
|
|
|
|
const Option MArch = Opts.getOption(options::OPT_march_EQ);
|
2009-09-10 06:33:15 +08:00
|
|
|
|
|
|
|
// This code must be kept in sync with LLVM's getArchTypeForDarwinArch,
|
|
|
|
// which defines the list of which architectures we accept.
|
|
|
|
if (Name == "ppc")
|
|
|
|
;
|
|
|
|
else if (Name == "ppc601")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "601");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "ppc603")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "603");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "ppc604")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "604");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "ppc604e")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "604e");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "ppc750")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "750");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "ppc7400")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "7400");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "ppc7450")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "7450");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "ppc970")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MCpu, "970");
|
2009-09-10 06:33:15 +08:00
|
|
|
|
|
|
|
else if (Name == "ppc64")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(0, Opts.getOption(options::OPT_m64));
|
2009-09-10 06:33:15 +08:00
|
|
|
|
|
|
|
else if (Name == "i386")
|
|
|
|
;
|
|
|
|
else if (Name == "i486")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "i486");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "i586")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "i586");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "i686")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "i686");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "pentium")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "pentium");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "pentium2")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "pentium2");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "pentpro")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "pentiumpro");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "pentIIm3")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "pentium2");
|
2009-09-10 06:33:15 +08:00
|
|
|
|
|
|
|
else if (Name == "x86_64")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddFlagArg(0, Opts.getOption(options::OPT_m64));
|
2009-03-25 14:58:31 +08:00
|
|
|
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "arm")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "armv4t");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "armv4t")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "armv4t");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "armv5")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "armv5tej");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "xscale")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "xscale");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "armv6")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "armv6k");
|
2013-03-05 06:37:49 +08:00
|
|
|
else if (Name == "armv6m")
|
|
|
|
DAL->AddJoinedArg(0, MArch, "armv6m");
|
2009-09-10 06:33:15 +08:00
|
|
|
else if (Name == "armv7")
|
2010-06-15 04:20:41 +08:00
|
|
|
DAL->AddJoinedArg(0, MArch, "armv7a");
|
2013-03-05 06:37:49 +08:00
|
|
|
else if (Name == "armv7em")
|
|
|
|
DAL->AddJoinedArg(0, MArch, "armv7em");
|
2012-09-30 07:52:50 +08:00
|
|
|
else if (Name == "armv7f")
|
|
|
|
DAL->AddJoinedArg(0, MArch, "armv7f");
|
|
|
|
else if (Name == "armv7k")
|
|
|
|
DAL->AddJoinedArg(0, MArch, "armv7k");
|
2013-03-05 06:37:49 +08:00
|
|
|
else if (Name == "armv7m")
|
|
|
|
DAL->AddJoinedArg(0, MArch, "armv7m");
|
2012-09-30 07:52:50 +08:00
|
|
|
else if (Name == "armv7s")
|
|
|
|
DAL->AddJoinedArg(0, MArch, "armv7s");
|
2009-09-10 06:33:15 +08:00
|
|
|
|
|
|
|
else
|
2009-12-12 13:05:38 +08:00
|
|
|
llvm_unreachable("invalid Darwin arch");
|
2009-09-10 06:33:15 +08:00
|
|
|
}
|
2009-03-25 14:58:31 +08:00
|
|
|
|
2010-07-20 01:11:36 +08:00
|
|
|
// Add an explicit version min argument for the deployment target. We do this
|
|
|
|
// after argument translation because -Xarch_ arguments may add a version min
|
|
|
|
// argument.
|
2012-04-28 03:51:11 +08:00
|
|
|
if (BoundArch)
|
|
|
|
AddDeploymentTarget(*DAL);
|
2010-07-20 01:11:36 +08:00
|
|
|
|
2012-10-16 06:23:53 +08:00
|
|
|
// For iOS 6, undo the translation to add -static for -mkernel/-fapple-kext.
|
|
|
|
// FIXME: It would be far better to avoid inserting those -static arguments,
|
|
|
|
// but we can't check the deployment target in the translation code until
|
|
|
|
// it is set here.
|
|
|
|
if (isTargetIPhoneOS() && !isIPhoneOSVersionLT(6, 0)) {
|
|
|
|
for (ArgList::iterator it = DAL->begin(), ie = DAL->end(); it != ie; ) {
|
|
|
|
Arg *A = *it;
|
|
|
|
++it;
|
|
|
|
if (A->getOption().getID() != options::OPT_mkernel &&
|
|
|
|
A->getOption().getID() != options::OPT_fapple_kext)
|
|
|
|
continue;
|
|
|
|
assert(it != ie && "unexpected argument translation");
|
|
|
|
A = *it;
|
|
|
|
assert(A->getOption().getID() == options::OPT_static &&
|
|
|
|
"missing expected -static argument");
|
|
|
|
it = DAL->getArgs().erase(it);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-10-08 01:54:41 +08:00
|
|
|
// Validate the C++ standard library choice.
|
|
|
|
CXXStdlibType Type = GetCXXStdlibType(*DAL);
|
|
|
|
if (Type == ToolChain::CST_Libcxx) {
|
2012-06-20 14:18:46 +08:00
|
|
|
// Check whether the target provides libc++.
|
|
|
|
StringRef where;
|
|
|
|
|
|
|
|
// Complain about targetting iOS < 5.0 in any way.
|
2012-11-09 09:59:30 +08:00
|
|
|
if (isTargetIPhoneOS() && isIPhoneOSVersionLT(5, 0))
|
|
|
|
where = "iOS 5.0";
|
2012-06-20 14:18:46 +08:00
|
|
|
|
|
|
|
if (where != StringRef()) {
|
2011-10-08 01:54:41 +08:00
|
|
|
getDriver().Diag(clang::diag::err_drv_invalid_libcxx_deployment)
|
2012-06-20 14:18:46 +08:00
|
|
|
<< where;
|
2011-10-08 01:54:41 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-03-25 14:12:34 +08:00
|
|
|
return DAL;
|
2009-09-09 23:08:12 +08:00
|
|
|
}
|
2009-03-20 08:57:52 +08:00
|
|
|
|
2009-09-05 02:34:51 +08:00
|
|
|
bool Darwin::IsUnwindTablesDefault() const {
|
2012-10-07 11:23:40 +08:00
|
|
|
return getArch() == llvm::Triple::x86_64;
|
2009-03-20 08:57:52 +08:00
|
|
|
}
|
|
|
|
|
2009-12-18 10:43:17 +08:00
|
|
|
bool Darwin::UseDwarfDebugFlags() const {
|
|
|
|
if (const char *S = ::getenv("RC_DEBUG_OPTIONS"))
|
|
|
|
return S[0] != '\0';
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2010-02-11 02:49:11 +08:00
|
|
|
bool Darwin::UseSjLjExceptions() const {
|
|
|
|
// Darwin uses SjLj exceptions on ARM.
|
|
|
|
return (getTriple().getArch() == llvm::Triple::arm ||
|
|
|
|
getTriple().getArch() == llvm::Triple::thumb);
|
|
|
|
}
|
|
|
|
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
bool Darwin::isPICDefault() const {
|
|
|
|
return true;
|
2009-03-20 08:57:52 +08:00
|
|
|
}
|
|
|
|
|
2013-04-09 12:35:11 +08:00
|
|
|
bool Darwin::isPIEDefault() const {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
bool Darwin::isPICDefaultForced() const {
|
|
|
|
return getArch() == llvm::Triple::x86_64;
|
2009-03-20 08:57:52 +08:00
|
|
|
}
|
|
|
|
|
2011-03-02 02:49:30 +08:00
|
|
|
bool Darwin::SupportsProfiling() const {
|
|
|
|
// Profiling instrumentation is only supported on x86.
|
2012-10-07 12:44:33 +08:00
|
|
|
return getArch() == llvm::Triple::x86 || getArch() == llvm::Triple::x86_64;
|
2011-03-02 02:49:30 +08:00
|
|
|
}
|
|
|
|
|
2010-04-11 00:20:23 +08:00
|
|
|
bool Darwin::SupportsObjCGC() const {
|
|
|
|
// Garbage collection is supported everywhere except on iPhone OS.
|
|
|
|
return !isTargetIPhoneOS();
|
|
|
|
}
|
|
|
|
|
2012-08-21 10:47:43 +08:00
|
|
|
void Darwin::CheckObjCARC() const {
|
|
|
|
if (isTargetIPhoneOS() || !isMacosxVersionLT(10, 6))
|
|
|
|
return;
|
2012-08-27 09:56:21 +08:00
|
|
|
getDriver().Diag(diag::err_arc_unsupported_on_toolchain);
|
2012-02-29 11:43:52 +08:00
|
|
|
}
|
|
|
|
|
2010-08-24 06:35:37 +08:00
|
|
|
std::string
|
2011-09-21 04:44:06 +08:00
|
|
|
Darwin_Generic_GCC::ComputeEffectiveClangTriple(const ArgList &Args,
|
|
|
|
types::ID InputType) const {
|
|
|
|
return ComputeLLVMTriple(Args, InputType);
|
2010-08-24 06:35:37 +08:00
|
|
|
}
|
|
|
|
|
2009-03-20 08:20:03 +08:00
|
|
|
/// Generic_GCC - A tool chain using the 'gcc' command to perform
|
|
|
|
/// all subcommands; this relies on gcc translating the majority of
|
|
|
|
/// command line options.
|
|
|
|
|
2011-11-07 07:39:34 +08:00
|
|
|
/// \brief Parse a GCCVersion object out of a string of text.
|
|
|
|
///
|
|
|
|
/// This is the primary means of forming GCCVersion objects.
|
|
|
|
/*static*/
|
|
|
|
Generic_GCC::GCCVersion Linux::GCCVersion::Parse(StringRef VersionText) {
|
|
|
|
const GCCVersion BadVersion = { VersionText.str(), -1, -1, -1, "" };
|
|
|
|
std::pair<StringRef, StringRef> First = VersionText.split('.');
|
|
|
|
std::pair<StringRef, StringRef> Second = First.second.split('.');
|
|
|
|
|
|
|
|
GCCVersion GoodVersion = { VersionText.str(), -1, -1, -1, "" };
|
|
|
|
if (First.first.getAsInteger(10, GoodVersion.Major) ||
|
|
|
|
GoodVersion.Major < 0)
|
|
|
|
return BadVersion;
|
|
|
|
if (Second.first.getAsInteger(10, GoodVersion.Minor) ||
|
|
|
|
GoodVersion.Minor < 0)
|
|
|
|
return BadVersion;
|
|
|
|
|
|
|
|
// First look for a number prefix and parse that if present. Otherwise just
|
|
|
|
// stash the entire patch string in the suffix, and leave the number
|
|
|
|
// unspecified. This covers versions strings such as:
|
|
|
|
// 4.4
|
|
|
|
// 4.4.0
|
|
|
|
// 4.4.x
|
|
|
|
// 4.4.2-rc4
|
|
|
|
// 4.4.x-patched
|
|
|
|
// And retains any patch number it finds.
|
|
|
|
StringRef PatchText = GoodVersion.PatchSuffix = Second.second.str();
|
|
|
|
if (!PatchText.empty()) {
|
2013-01-11 06:20:02 +08:00
|
|
|
if (size_t EndNumber = PatchText.find_first_not_of("0123456789")) {
|
2011-11-07 07:39:34 +08:00
|
|
|
// Try to parse the number and any suffix.
|
|
|
|
if (PatchText.slice(0, EndNumber).getAsInteger(10, GoodVersion.Patch) ||
|
|
|
|
GoodVersion.Patch < 0)
|
|
|
|
return BadVersion;
|
|
|
|
GoodVersion.PatchSuffix = PatchText.substr(EndNumber).str();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return GoodVersion;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Less-than for GCCVersion, implementing a Strict Weak Ordering.
|
|
|
|
bool Generic_GCC::GCCVersion::operator<(const GCCVersion &RHS) const {
|
2012-12-29 20:01:08 +08:00
|
|
|
if (Major != RHS.Major)
|
|
|
|
return Major < RHS.Major;
|
|
|
|
if (Minor != RHS.Minor)
|
|
|
|
return Minor < RHS.Minor;
|
|
|
|
if (Patch != RHS.Patch) {
|
|
|
|
// Note that versions without a specified patch sort higher than those with
|
|
|
|
// a patch.
|
|
|
|
if (RHS.Patch == -1)
|
|
|
|
return true;
|
|
|
|
if (Patch == -1)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Otherwise just sort on the patch itself.
|
|
|
|
return Patch < RHS.Patch;
|
|
|
|
}
|
|
|
|
if (PatchSuffix != RHS.PatchSuffix) {
|
|
|
|
// Sort empty suffixes higher.
|
|
|
|
if (RHS.PatchSuffix.empty())
|
|
|
|
return true;
|
|
|
|
if (PatchSuffix.empty())
|
2012-12-29 21:00:47 +08:00
|
|
|
return false;
|
2012-12-29 20:01:08 +08:00
|
|
|
|
|
|
|
// Provide a lexicographic sort to make this a total ordering.
|
|
|
|
return PatchSuffix < RHS.PatchSuffix;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The versions are equal.
|
2011-11-07 07:39:34 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
static StringRef getGCCToolchainDir(const ArgList &Args) {
|
|
|
|
const Arg *A = Args.getLastArg(options::OPT_gcc_toolchain);
|
|
|
|
if (A)
|
2012-11-01 12:30:05 +08:00
|
|
|
return A->getValue();
|
2012-02-19 09:38:32 +08:00
|
|
|
return GCC_INSTALL_PREFIX;
|
|
|
|
}
|
|
|
|
|
2011-11-07 07:39:34 +08:00
|
|
|
/// \brief Construct a GCCInstallationDetector from the driver.
|
|
|
|
///
|
|
|
|
/// This performs all of the autodetection and sets up the various paths.
|
2012-04-17 19:16:26 +08:00
|
|
|
/// Once constructed, a GCCInstallationDetector is essentially immutable.
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
///
|
|
|
|
/// FIXME: We shouldn't need an explicit TargetTriple parameter here, and
|
|
|
|
/// should instead pull the target out of the driver. This is currently
|
|
|
|
/// necessary because the driver doesn't store the final version of the target
|
|
|
|
/// triple.
|
|
|
|
Generic_GCC::GCCInstallationDetector::GCCInstallationDetector(
|
|
|
|
const Driver &D,
|
2012-02-19 09:38:32 +08:00
|
|
|
const llvm::Triple &TargetTriple,
|
|
|
|
const ArgList &Args)
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
: IsValid(false) {
|
2012-02-13 10:02:09 +08:00
|
|
|
llvm::Triple MultiarchTriple
|
|
|
|
= TargetTriple.isArch32Bit() ? TargetTriple.get64BitArchVariant()
|
|
|
|
: TargetTriple.get32BitArchVariant();
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
llvm::Triple::ArchType TargetArch = TargetTriple.getArch();
|
2011-11-07 07:39:34 +08:00
|
|
|
// The library directories which may contain GCC installations.
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
SmallVector<StringRef, 4> CandidateLibDirs, CandidateMultiarchLibDirs;
|
2011-11-07 07:39:34 +08:00
|
|
|
// The compatible GCC triples for this particular architecture.
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
SmallVector<StringRef, 10> CandidateTripleAliases;
|
|
|
|
SmallVector<StringRef, 10> CandidateMultiarchTripleAliases;
|
|
|
|
CollectLibDirsAndTriples(TargetTriple, MultiarchTriple, CandidateLibDirs,
|
|
|
|
CandidateTripleAliases,
|
|
|
|
CandidateMultiarchLibDirs,
|
|
|
|
CandidateMultiarchTripleAliases);
|
2011-11-07 07:39:34 +08:00
|
|
|
|
|
|
|
// Compute the set of prefixes for our search.
|
|
|
|
SmallVector<std::string, 8> Prefixes(D.PrefixDirs.begin(),
|
|
|
|
D.PrefixDirs.end());
|
2012-02-03 09:01:20 +08:00
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
StringRef GCCToolchainDir = getGCCToolchainDir(Args);
|
|
|
|
if (GCCToolchainDir != "") {
|
|
|
|
if (GCCToolchainDir.back() == '/')
|
|
|
|
GCCToolchainDir = GCCToolchainDir.drop_back(); // remove the /
|
2012-02-03 09:01:20 +08:00
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
Prefixes.push_back(GCCToolchainDir);
|
2012-02-03 09:01:20 +08:00
|
|
|
} else {
|
|
|
|
Prefixes.push_back(D.SysRoot);
|
|
|
|
Prefixes.push_back(D.SysRoot + "/usr");
|
|
|
|
Prefixes.push_back(D.InstalledDir + "/..");
|
|
|
|
}
|
2011-11-07 07:39:34 +08:00
|
|
|
|
|
|
|
// Loop over the various components which exist and select the best GCC
|
|
|
|
// installation available. GCC installs are ranked by version number.
|
|
|
|
Version = GCCVersion::Parse("0.0.0");
|
|
|
|
for (unsigned i = 0, ie = Prefixes.size(); i < ie; ++i) {
|
|
|
|
if (!llvm::sys::fs::exists(Prefixes[i]))
|
|
|
|
continue;
|
|
|
|
for (unsigned j = 0, je = CandidateLibDirs.size(); j < je; ++j) {
|
|
|
|
const std::string LibDir = Prefixes[i] + CandidateLibDirs[j].str();
|
|
|
|
if (!llvm::sys::fs::exists(LibDir))
|
|
|
|
continue;
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
for (unsigned k = 0, ke = CandidateTripleAliases.size(); k < ke; ++k)
|
2012-10-21 19:44:57 +08:00
|
|
|
ScanLibDirForGCCTriple(TargetArch, Args, LibDir,
|
|
|
|
CandidateTripleAliases[k]);
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
}
|
|
|
|
for (unsigned j = 0, je = CandidateMultiarchLibDirs.size(); j < je; ++j) {
|
|
|
|
const std::string LibDir
|
|
|
|
= Prefixes[i] + CandidateMultiarchLibDirs[j].str();
|
|
|
|
if (!llvm::sys::fs::exists(LibDir))
|
|
|
|
continue;
|
|
|
|
for (unsigned k = 0, ke = CandidateMultiarchTripleAliases.size(); k < ke;
|
|
|
|
++k)
|
2012-10-21 19:44:57 +08:00
|
|
|
ScanLibDirForGCCTriple(TargetArch, Args, LibDir,
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
CandidateMultiarchTripleAliases[k],
|
|
|
|
/*NeedsMultiarchSuffix=*/true);
|
2011-11-07 07:39:34 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*static*/ void Generic_GCC::GCCInstallationDetector::CollectLibDirsAndTriples(
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
const llvm::Triple &TargetTriple,
|
|
|
|
const llvm::Triple &MultiarchTriple,
|
|
|
|
SmallVectorImpl<StringRef> &LibDirs,
|
|
|
|
SmallVectorImpl<StringRef> &TripleAliases,
|
|
|
|
SmallVectorImpl<StringRef> &MultiarchLibDirs,
|
|
|
|
SmallVectorImpl<StringRef> &MultiarchTripleAliases) {
|
|
|
|
// Declare a bunch of static data sets that we'll select between below. These
|
|
|
|
// are specifically designed to always refer to string literals to avoid any
|
|
|
|
// lifetime or initialization issues.
|
2013-01-31 20:13:10 +08:00
|
|
|
static const char *const AArch64LibDirs[] = { "/lib" };
|
|
|
|
static const char *const AArch64Triples[] = {
|
|
|
|
"aarch64-none-linux-gnu",
|
|
|
|
"aarch64-linux-gnu"
|
|
|
|
};
|
|
|
|
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
static const char *const ARMLibDirs[] = { "/lib" };
|
|
|
|
static const char *const ARMTriples[] = {
|
|
|
|
"arm-linux-gnueabi",
|
|
|
|
"arm-linux-androideabi"
|
|
|
|
};
|
2012-07-31 16:06:29 +08:00
|
|
|
static const char *const ARMHFTriples[] = {
|
|
|
|
"arm-linux-gnueabihf",
|
2013-04-14 18:14:21 +08:00
|
|
|
"armv7hl-redhat-linux-gnueabi"
|
2012-07-31 16:06:29 +08:00
|
|
|
};
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
|
|
|
|
static const char *const X86_64LibDirs[] = { "/lib64", "/lib" };
|
|
|
|
static const char *const X86_64Triples[] = {
|
|
|
|
"x86_64-linux-gnu",
|
|
|
|
"x86_64-unknown-linux-gnu",
|
|
|
|
"x86_64-pc-linux-gnu",
|
|
|
|
"x86_64-redhat-linux6E",
|
|
|
|
"x86_64-redhat-linux",
|
|
|
|
"x86_64-suse-linux",
|
|
|
|
"x86_64-manbo-linux-gnu",
|
|
|
|
"x86_64-linux-gnu",
|
|
|
|
"x86_64-slackware-linux"
|
|
|
|
};
|
|
|
|
static const char *const X86LibDirs[] = { "/lib32", "/lib" };
|
|
|
|
static const char *const X86Triples[] = {
|
|
|
|
"i686-linux-gnu",
|
|
|
|
"i686-pc-linux-gnu",
|
|
|
|
"i486-linux-gnu",
|
|
|
|
"i386-linux-gnu",
|
2012-12-08 01:13:18 +08:00
|
|
|
"i386-redhat-linux6E",
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
"i686-redhat-linux",
|
|
|
|
"i586-redhat-linux",
|
|
|
|
"i386-redhat-linux",
|
|
|
|
"i586-suse-linux",
|
2012-05-15 19:21:03 +08:00
|
|
|
"i486-slackware-linux",
|
|
|
|
"i686-montavista-linux"
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char *const MIPSLibDirs[] = { "/lib" };
|
|
|
|
static const char *const MIPSTriples[] = { "mips-linux-gnu" };
|
|
|
|
static const char *const MIPSELLibDirs[] = { "/lib" };
|
2012-10-04 01:46:38 +08:00
|
|
|
static const char *const MIPSELTriples[] = {
|
|
|
|
"mipsel-linux-gnu",
|
2013-04-20 16:15:03 +08:00
|
|
|
"mipsel-linux-android",
|
|
|
|
"mips-linux-gnu"
|
2012-10-04 01:46:38 +08:00
|
|
|
};
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
|
2012-04-27 03:57:02 +08:00
|
|
|
static const char *const MIPS64LibDirs[] = { "/lib64", "/lib" };
|
|
|
|
static const char *const MIPS64Triples[] = { "mips64-linux-gnu" };
|
|
|
|
static const char *const MIPS64ELLibDirs[] = { "/lib64", "/lib" };
|
|
|
|
static const char *const MIPS64ELTriples[] = { "mips64el-linux-gnu" };
|
|
|
|
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
static const char *const PPCLibDirs[] = { "/lib32", "/lib" };
|
|
|
|
static const char *const PPCTriples[] = {
|
|
|
|
"powerpc-linux-gnu",
|
|
|
|
"powerpc-unknown-linux-gnu",
|
2013-03-16 00:22:43 +08:00
|
|
|
"powerpc-linux-gnuspe",
|
2012-05-15 19:21:03 +08:00
|
|
|
"powerpc-suse-linux",
|
|
|
|
"powerpc-montavista-linuxspe"
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
};
|
|
|
|
static const char *const PPC64LibDirs[] = { "/lib64", "/lib" };
|
|
|
|
static const char *const PPC64Triples[] = {
|
2012-02-26 17:03:21 +08:00
|
|
|
"powerpc64-linux-gnu",
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
"powerpc64-unknown-linux-gnu",
|
|
|
|
"powerpc64-suse-linux",
|
|
|
|
"ppc64-redhat-linux"
|
|
|
|
};
|
|
|
|
|
|
|
|
switch (TargetTriple.getArch()) {
|
2013-01-31 20:13:10 +08:00
|
|
|
case llvm::Triple::aarch64:
|
2013-02-05 15:29:49 +08:00
|
|
|
LibDirs.append(AArch64LibDirs, AArch64LibDirs
|
2013-01-31 20:13:10 +08:00
|
|
|
+ llvm::array_lengthof(AArch64LibDirs));
|
|
|
|
TripleAliases.append(
|
|
|
|
AArch64Triples, AArch64Triples + llvm::array_lengthof(AArch64Triples));
|
|
|
|
MultiarchLibDirs.append(
|
|
|
|
AArch64LibDirs, AArch64LibDirs + llvm::array_lengthof(AArch64LibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
AArch64Triples, AArch64Triples + llvm::array_lengthof(AArch64Triples));
|
|
|
|
break;
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
case llvm::Triple::arm:
|
|
|
|
case llvm::Triple::thumb:
|
2011-11-07 07:39:34 +08:00
|
|
|
LibDirs.append(ARMLibDirs, ARMLibDirs + llvm::array_lengthof(ARMLibDirs));
|
2012-07-31 16:06:29 +08:00
|
|
|
if (TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF) {
|
|
|
|
TripleAliases.append(
|
|
|
|
ARMHFTriples, ARMHFTriples + llvm::array_lengthof(ARMHFTriples));
|
|
|
|
} else {
|
|
|
|
TripleAliases.append(
|
|
|
|
ARMTriples, ARMTriples + llvm::array_lengthof(ARMTriples));
|
|
|
|
}
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
break;
|
|
|
|
case llvm::Triple::x86_64:
|
|
|
|
LibDirs.append(
|
|
|
|
X86_64LibDirs, X86_64LibDirs + llvm::array_lengthof(X86_64LibDirs));
|
|
|
|
TripleAliases.append(
|
|
|
|
X86_64Triples, X86_64Triples + llvm::array_lengthof(X86_64Triples));
|
|
|
|
MultiarchLibDirs.append(
|
|
|
|
X86LibDirs, X86LibDirs + llvm::array_lengthof(X86LibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
X86Triples, X86Triples + llvm::array_lengthof(X86Triples));
|
|
|
|
break;
|
|
|
|
case llvm::Triple::x86:
|
2011-11-07 07:39:34 +08:00
|
|
|
LibDirs.append(X86LibDirs, X86LibDirs + llvm::array_lengthof(X86LibDirs));
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
TripleAliases.append(
|
|
|
|
X86Triples, X86Triples + llvm::array_lengthof(X86Triples));
|
|
|
|
MultiarchLibDirs.append(
|
|
|
|
X86_64LibDirs, X86_64LibDirs + llvm::array_lengthof(X86_64LibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
X86_64Triples, X86_64Triples + llvm::array_lengthof(X86_64Triples));
|
|
|
|
break;
|
|
|
|
case llvm::Triple::mips:
|
|
|
|
LibDirs.append(
|
|
|
|
MIPSLibDirs, MIPSLibDirs + llvm::array_lengthof(MIPSLibDirs));
|
|
|
|
TripleAliases.append(
|
|
|
|
MIPSTriples, MIPSTriples + llvm::array_lengthof(MIPSTriples));
|
2012-04-27 03:57:02 +08:00
|
|
|
MultiarchLibDirs.append(
|
|
|
|
MIPS64LibDirs, MIPS64LibDirs + llvm::array_lengthof(MIPS64LibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
MIPS64Triples, MIPS64Triples + llvm::array_lengthof(MIPS64Triples));
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
break;
|
|
|
|
case llvm::Triple::mipsel:
|
|
|
|
LibDirs.append(
|
|
|
|
MIPSELLibDirs, MIPSELLibDirs + llvm::array_lengthof(MIPSELLibDirs));
|
|
|
|
TripleAliases.append(
|
|
|
|
MIPSELTriples, MIPSELTriples + llvm::array_lengthof(MIPSELTriples));
|
2012-04-27 03:57:02 +08:00
|
|
|
MultiarchLibDirs.append(
|
|
|
|
MIPS64ELLibDirs, MIPS64ELLibDirs + llvm::array_lengthof(MIPS64ELLibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
MIPS64ELTriples, MIPS64ELTriples + llvm::array_lengthof(MIPS64ELTriples));
|
|
|
|
break;
|
|
|
|
case llvm::Triple::mips64:
|
|
|
|
LibDirs.append(
|
|
|
|
MIPS64LibDirs, MIPS64LibDirs + llvm::array_lengthof(MIPS64LibDirs));
|
|
|
|
TripleAliases.append(
|
|
|
|
MIPS64Triples, MIPS64Triples + llvm::array_lengthof(MIPS64Triples));
|
|
|
|
MultiarchLibDirs.append(
|
|
|
|
MIPSLibDirs, MIPSLibDirs + llvm::array_lengthof(MIPSLibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
MIPSTriples, MIPSTriples + llvm::array_lengthof(MIPSTriples));
|
|
|
|
break;
|
|
|
|
case llvm::Triple::mips64el:
|
|
|
|
LibDirs.append(
|
|
|
|
MIPS64ELLibDirs, MIPS64ELLibDirs + llvm::array_lengthof(MIPS64ELLibDirs));
|
|
|
|
TripleAliases.append(
|
|
|
|
MIPS64ELTriples, MIPS64ELTriples + llvm::array_lengthof(MIPS64ELTriples));
|
|
|
|
MultiarchLibDirs.append(
|
|
|
|
MIPSELLibDirs, MIPSELLibDirs + llvm::array_lengthof(MIPSELLibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
MIPSELTriples, MIPSELTriples + llvm::array_lengthof(MIPSELTriples));
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
break;
|
|
|
|
case llvm::Triple::ppc:
|
2011-11-07 07:39:34 +08:00
|
|
|
LibDirs.append(PPCLibDirs, PPCLibDirs + llvm::array_lengthof(PPCLibDirs));
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
TripleAliases.append(
|
|
|
|
PPCTriples, PPCTriples + llvm::array_lengthof(PPCTriples));
|
|
|
|
MultiarchLibDirs.append(
|
|
|
|
PPC64LibDirs, PPC64LibDirs + llvm::array_lengthof(PPC64LibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
PPC64Triples, PPC64Triples + llvm::array_lengthof(PPC64Triples));
|
|
|
|
break;
|
|
|
|
case llvm::Triple::ppc64:
|
|
|
|
LibDirs.append(
|
|
|
|
PPC64LibDirs, PPC64LibDirs + llvm::array_lengthof(PPC64LibDirs));
|
|
|
|
TripleAliases.append(
|
|
|
|
PPC64Triples, PPC64Triples + llvm::array_lengthof(PPC64Triples));
|
|
|
|
MultiarchLibDirs.append(
|
|
|
|
PPCLibDirs, PPCLibDirs + llvm::array_lengthof(PPCLibDirs));
|
|
|
|
MultiarchTripleAliases.append(
|
|
|
|
PPCTriples, PPCTriples + llvm::array_lengthof(PPCTriples));
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
// By default, just rely on the standard lib directories and the original
|
|
|
|
// triple.
|
|
|
|
break;
|
2011-11-07 07:39:34 +08:00
|
|
|
}
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
|
|
|
|
// Always append the drivers target triple to the end, in case it doesn't
|
|
|
|
// match any of our aliases.
|
|
|
|
TripleAliases.push_back(TargetTriple.str());
|
|
|
|
|
|
|
|
// Also include the multiarch variant if it's different.
|
|
|
|
if (TargetTriple.str() != MultiarchTriple.str())
|
|
|
|
MultiarchTripleAliases.push_back(MultiarchTriple.str());
|
2011-11-07 07:39:34 +08:00
|
|
|
}
|
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
static bool isSoftFloatABI(const ArgList &Args) {
|
|
|
|
Arg *A = Args.getLastArg(options::OPT_msoft_float,
|
|
|
|
options::OPT_mhard_float,
|
|
|
|
options::OPT_mfloat_abi_EQ);
|
|
|
|
if (!A) return false;
|
|
|
|
|
|
|
|
return A->getOption().matches(options::OPT_msoft_float) ||
|
|
|
|
(A->getOption().matches(options::OPT_mfloat_abi_EQ) &&
|
|
|
|
A->getValue() == StringRef("soft"));
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool isMipsArch(llvm::Triple::ArchType Arch) {
|
|
|
|
return Arch == llvm::Triple::mips ||
|
|
|
|
Arch == llvm::Triple::mipsel ||
|
|
|
|
Arch == llvm::Triple::mips64 ||
|
|
|
|
Arch == llvm::Triple::mips64el;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool isMips16(const ArgList &Args) {
|
|
|
|
Arg *A = Args.getLastArg(options::OPT_mips16,
|
|
|
|
options::OPT_mno_mips16);
|
|
|
|
return A && A->getOption().matches(options::OPT_mips16);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool isMicroMips(const ArgList &Args) {
|
|
|
|
Arg *A = Args.getLastArg(options::OPT_mmicromips,
|
|
|
|
options::OPT_mno_micromips);
|
|
|
|
return A && A->getOption().matches(options::OPT_mmicromips);
|
|
|
|
}
|
|
|
|
|
2012-10-21 19:44:57 +08:00
|
|
|
// FIXME: There is the same routine in the Tools.cpp.
|
|
|
|
static bool hasMipsN32ABIArg(const ArgList &Args) {
|
|
|
|
Arg *A = Args.getLastArg(options::OPT_mabi_EQ);
|
2012-11-01 12:30:05 +08:00
|
|
|
return A && (A->getValue() == StringRef("n32"));
|
2012-10-21 19:44:57 +08:00
|
|
|
}
|
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
static void appendMipsTargetSuffix(SmallVectorImpl<char> &Path,
|
|
|
|
llvm::Triple::ArchType TargetArch,
|
|
|
|
const ArgList &Args) {
|
|
|
|
if (isMips16(Args))
|
|
|
|
llvm::sys::path::append(Path, "/mips16");
|
|
|
|
else if (isMicroMips(Args))
|
|
|
|
llvm::sys::path::append(Path, "/micromips");
|
|
|
|
|
|
|
|
if (isSoftFloatABI(Args))
|
|
|
|
llvm::sys::path::append(Path, "/soft-float");
|
2012-10-21 19:44:57 +08:00
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
if (TargetArch == llvm::Triple::mipsel ||
|
|
|
|
TargetArch == llvm::Triple::mips64el)
|
|
|
|
llvm::sys::path::append(Path, "/el");
|
|
|
|
}
|
|
|
|
|
|
|
|
static StringRef getMipsTargetABISuffix(llvm::Triple::ArchType TargetArch,
|
|
|
|
const ArgList &Args) {
|
2012-10-21 19:44:57 +08:00
|
|
|
if (TargetArch == llvm::Triple::mips64 ||
|
2013-04-20 16:15:03 +08:00
|
|
|
TargetArch == llvm::Triple::mips64el)
|
|
|
|
return hasMipsN32ABIArg(Args) ? "/n32" : "/64";
|
2012-10-21 19:44:57 +08:00
|
|
|
|
|
|
|
return "/32";
|
|
|
|
}
|
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
static bool findTargetMultiarchSuffix(SmallString<32> &Suffix,
|
|
|
|
StringRef Path,
|
|
|
|
llvm::Triple::ArchType TargetArch,
|
|
|
|
const ArgList &Args) {
|
|
|
|
if (isMipsArch(TargetArch)) {
|
|
|
|
StringRef ABISuffix = getMipsTargetABISuffix(TargetArch, Args);
|
|
|
|
|
|
|
|
// First build and check a complex path to crtbegin.o
|
|
|
|
// depends on command line options (-mips16, -msoft-float, ...)
|
|
|
|
// like mips-linux-gnu/4.7/mips16/soft-float/el/crtbegin.o
|
|
|
|
appendMipsTargetSuffix(Suffix, TargetArch, Args);
|
|
|
|
|
|
|
|
if (TargetArch == llvm::Triple::mips64 ||
|
|
|
|
TargetArch == llvm::Triple::mips64el)
|
|
|
|
llvm::sys::path::append(Suffix, ABISuffix);
|
|
|
|
|
|
|
|
if (llvm::sys::fs::exists(Path + Suffix.str() + "/crtbegin.o"))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Then fall back and probe a simple case like
|
|
|
|
// mips-linux-gnu/4.7/32/crtbegin.o
|
|
|
|
Suffix = ABISuffix;
|
|
|
|
return llvm::sys::fs::exists(Path + Suffix.str() + "/crtbegin.o");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (TargetArch == llvm::Triple::x86_64 ||
|
|
|
|
TargetArch == llvm::Triple::ppc64)
|
|
|
|
Suffix = "/64";
|
|
|
|
else
|
|
|
|
Suffix = "/32";
|
|
|
|
|
|
|
|
return llvm::sys::fs::exists(Path + Suffix.str() + "/crtbegin.o");
|
|
|
|
}
|
|
|
|
|
2011-11-07 07:39:34 +08:00
|
|
|
void Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
|
2012-10-21 19:44:57 +08:00
|
|
|
llvm::Triple::ArchType TargetArch, const ArgList &Args,
|
|
|
|
const std::string &LibDir,
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
StringRef CandidateTriple, bool NeedsMultiarchSuffix) {
|
2011-11-07 07:39:34 +08:00
|
|
|
// There are various different suffixes involving the triple we
|
|
|
|
// check for. We also record what is necessary to walk from each back
|
|
|
|
// up to the lib directory.
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
const std::string LibSuffixes[] = {
|
2011-11-07 07:39:34 +08:00
|
|
|
"/gcc/" + CandidateTriple.str(),
|
|
|
|
"/" + CandidateTriple.str() + "/gcc/" + CandidateTriple.str(),
|
|
|
|
|
2012-09-19 06:25:07 +08:00
|
|
|
// The Freescale PPC SDK has the gcc libraries in
|
|
|
|
// <sysroot>/usr/lib/<triple>/x.y.z so have a look there as well.
|
|
|
|
"/" + CandidateTriple.str(),
|
|
|
|
|
2011-11-07 07:39:34 +08:00
|
|
|
// Ubuntu has a strange mis-matched pair of triples that this happens to
|
|
|
|
// match.
|
|
|
|
// FIXME: It may be worthwhile to generalize this and look for a second
|
|
|
|
// triple.
|
2011-11-09 11:46:20 +08:00
|
|
|
"/i386-linux-gnu/gcc/" + CandidateTriple.str()
|
2011-11-07 07:39:34 +08:00
|
|
|
};
|
|
|
|
const std::string InstallSuffixes[] = {
|
|
|
|
"/../../..",
|
|
|
|
"/../../../..",
|
2012-09-19 06:25:07 +08:00
|
|
|
"/../..",
|
2011-11-07 07:39:34 +08:00
|
|
|
"/../../../.."
|
|
|
|
};
|
|
|
|
// Only look at the final, weird Ubuntu suffix for i386-linux-gnu.
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
const unsigned NumLibSuffixes = (llvm::array_lengthof(LibSuffixes) -
|
|
|
|
(TargetArch != llvm::Triple::x86));
|
|
|
|
for (unsigned i = 0; i < NumLibSuffixes; ++i) {
|
|
|
|
StringRef LibSuffix = LibSuffixes[i];
|
2011-11-07 07:39:34 +08:00
|
|
|
llvm::error_code EC;
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
for (llvm::sys::fs::directory_iterator LI(LibDir + LibSuffix, EC), LE;
|
2011-11-07 07:39:34 +08:00
|
|
|
!EC && LI != LE; LI = LI.increment(EC)) {
|
|
|
|
StringRef VersionText = llvm::sys::path::filename(LI->path());
|
|
|
|
GCCVersion CandidateVersion = GCCVersion::Parse(VersionText);
|
|
|
|
static const GCCVersion MinVersion = { "4.1.1", 4, 1, 1, "" };
|
|
|
|
if (CandidateVersion < MinVersion)
|
|
|
|
continue;
|
|
|
|
if (CandidateVersion <= Version)
|
|
|
|
continue;
|
2011-12-08 13:50:03 +08:00
|
|
|
|
|
|
|
// Some versions of SUSE and Fedora on ppc64 put 32-bit libs
|
2012-01-25 03:21:42 +08:00
|
|
|
// in what would normally be GCCInstallPath and put the 64-bit
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
// libs in a subdirectory named 64. The simple logic we follow is that
|
|
|
|
// *if* there is a subdirectory of the right name with crtbegin.o in it,
|
|
|
|
// we use that. If not, and if not a multiarch triple, we look for
|
|
|
|
// crtbegin.o without the subdirectory.
|
2013-04-20 16:15:03 +08:00
|
|
|
|
|
|
|
SmallString<32> MultiarchSuffix;
|
|
|
|
if (findTargetMultiarchSuffix(MultiarchSuffix,
|
|
|
|
LI->path(), TargetArch, Args)) {
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
GCCMultiarchSuffix = MultiarchSuffix.str();
|
|
|
|
} else {
|
|
|
|
if (NeedsMultiarchSuffix ||
|
|
|
|
!llvm::sys::fs::exists(LI->path() + "/crtbegin.o"))
|
|
|
|
continue;
|
|
|
|
GCCMultiarchSuffix.clear();
|
|
|
|
}
|
2011-11-07 07:39:34 +08:00
|
|
|
|
|
|
|
Version = CandidateVersion;
|
2012-01-25 03:28:29 +08:00
|
|
|
GCCTriple.setTriple(CandidateTriple);
|
2011-11-07 07:39:34 +08:00
|
|
|
// FIXME: We hack together the directory name here instead of
|
|
|
|
// using LI to ensure stable path separators across Windows and
|
|
|
|
// Linux.
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
GCCInstallPath = LibDir + LibSuffixes[i] + "/" + VersionText.str();
|
2012-01-25 03:21:42 +08:00
|
|
|
GCCParentLibPath = GCCInstallPath + InstallSuffixes[i];
|
2011-11-07 07:39:34 +08:00
|
|
|
IsValid = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
Generic_GCC::Generic_GCC(const Driver &D, const llvm::Triple& Triple,
|
|
|
|
const ArgList &Args)
|
2013-03-19 02:10:27 +08:00
|
|
|
: ToolChain(D, Triple, Args), GCCInstallation(getDriver(), Triple, Args) {
|
2010-08-02 06:29:51 +08:00
|
|
|
getProgramPaths().push_back(getDriver().getInstalledDir());
|
2011-03-02 06:50:47 +08:00
|
|
|
if (getDriver().getInstalledDir() != getDriver().Dir)
|
2010-08-02 06:29:51 +08:00
|
|
|
getProgramPaths().push_back(getDriver().Dir);
|
2009-03-24 00:15:50 +08:00
|
|
|
}
|
|
|
|
|
2009-03-20 08:20:03 +08:00
|
|
|
Generic_GCC::~Generic_GCC() {
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Generic_GCC::getTool(Action::ActionClass AC) const {
|
2013-03-19 04:48:54 +08:00
|
|
|
switch (AC) {
|
2013-03-19 02:50:01 +08:00
|
|
|
case Action::PreprocessJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
if (!Preprocess)
|
|
|
|
Preprocess.reset(new tools::gcc::Preprocess(*this));
|
|
|
|
return Preprocess.get();
|
2013-03-19 02:50:01 +08:00
|
|
|
case Action::PrecompileJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
if (!Precompile)
|
|
|
|
Precompile.reset(new tools::gcc::Precompile(*this));
|
|
|
|
return Precompile.get();
|
2013-03-19 02:50:01 +08:00
|
|
|
case Action::CompileJobClass:
|
2013-03-20 11:05:54 +08:00
|
|
|
if (!Compile)
|
|
|
|
Compile.reset(new tools::gcc::Compile(*this));
|
|
|
|
return Compile.get();
|
2013-03-19 08:36:57 +08:00
|
|
|
default:
|
2013-03-20 11:05:54 +08:00
|
|
|
return ToolChain::getTool(AC);
|
2009-03-20 08:20:03 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Generic_GCC::buildAssembler() const {
|
|
|
|
return new tools::gcc::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Generic_GCC::buildLinker() const {
|
|
|
|
return new tools::gcc::Link(*this);
|
|
|
|
}
|
|
|
|
|
2009-03-20 08:20:03 +08:00
|
|
|
bool Generic_GCC::IsUnwindTablesDefault() const {
|
2012-09-22 23:04:11 +08:00
|
|
|
return getArch() == llvm::Triple::x86_64;
|
2009-03-20 08:20:03 +08:00
|
|
|
}
|
|
|
|
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
bool Generic_GCC::isPICDefault() const {
|
|
|
|
return false;
|
2009-03-20 08:20:03 +08:00
|
|
|
}
|
|
|
|
|
2013-04-09 12:35:11 +08:00
|
|
|
bool Generic_GCC::isPIEDefault() const {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
bool Generic_GCC::isPICDefaultForced() const {
|
|
|
|
return false;
|
2009-03-20 08:20:03 +08:00
|
|
|
}
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
|
2011-12-13 05:14:55 +08:00
|
|
|
/// Hexagon Toolchain
|
|
|
|
|
2012-12-06 20:43:18 +08:00
|
|
|
std::string Hexagon_TC::GetGnuDir(const std::string &InstalledDir) {
|
|
|
|
|
|
|
|
// Locate the rest of the toolchain ...
|
|
|
|
if (strlen(GCC_INSTALL_PREFIX))
|
|
|
|
return std::string(GCC_INSTALL_PREFIX);
|
|
|
|
|
|
|
|
std::string InstallRelDir = InstalledDir + "/../../gnu";
|
|
|
|
if (llvm::sys::fs::exists(InstallRelDir))
|
|
|
|
return InstallRelDir;
|
|
|
|
|
|
|
|
std::string PrefixRelDir = std::string(LLVM_PREFIX) + "/../gnu";
|
|
|
|
if (llvm::sys::fs::exists(PrefixRelDir))
|
|
|
|
return PrefixRelDir;
|
|
|
|
|
|
|
|
return InstallRelDir;
|
|
|
|
}
|
|
|
|
|
2012-12-06 23:46:07 +08:00
|
|
|
static void GetHexagonLibraryPaths(
|
|
|
|
const ArgList &Args,
|
|
|
|
const std::string Ver,
|
|
|
|
const std::string MarchString,
|
|
|
|
const std::string &InstalledDir,
|
|
|
|
ToolChain::path_list *LibPaths)
|
|
|
|
{
|
|
|
|
bool buildingLib = Args.hasArg(options::OPT_shared);
|
|
|
|
|
|
|
|
//----------------------------------------------------------------------------
|
|
|
|
// -L Args
|
|
|
|
//----------------------------------------------------------------------------
|
|
|
|
for (arg_iterator
|
|
|
|
it = Args.filtered_begin(options::OPT_L),
|
|
|
|
ie = Args.filtered_end();
|
|
|
|
it != ie;
|
|
|
|
++it) {
|
|
|
|
for (unsigned i = 0, e = (*it)->getNumValues(); i != e; ++i)
|
|
|
|
LibPaths->push_back((*it)->getValue(i));
|
|
|
|
}
|
|
|
|
|
|
|
|
//----------------------------------------------------------------------------
|
|
|
|
// Other standard paths
|
|
|
|
//----------------------------------------------------------------------------
|
|
|
|
const std::string MarchSuffix = "/" + MarchString;
|
|
|
|
const std::string G0Suffix = "/G0";
|
|
|
|
const std::string MarchG0Suffix = MarchSuffix + G0Suffix;
|
|
|
|
const std::string RootDir = Hexagon_TC::GetGnuDir(InstalledDir) + "/";
|
|
|
|
|
|
|
|
// lib/gcc/hexagon/...
|
|
|
|
std::string LibGCCHexagonDir = RootDir + "lib/gcc/hexagon/";
|
|
|
|
if (buildingLib) {
|
|
|
|
LibPaths->push_back(LibGCCHexagonDir + Ver + MarchG0Suffix);
|
|
|
|
LibPaths->push_back(LibGCCHexagonDir + Ver + G0Suffix);
|
|
|
|
}
|
|
|
|
LibPaths->push_back(LibGCCHexagonDir + Ver + MarchSuffix);
|
|
|
|
LibPaths->push_back(LibGCCHexagonDir + Ver);
|
|
|
|
|
|
|
|
// lib/gcc/...
|
|
|
|
LibPaths->push_back(RootDir + "lib/gcc");
|
|
|
|
|
|
|
|
// hexagon/lib/...
|
|
|
|
std::string HexagonLibDir = RootDir + "hexagon/lib";
|
|
|
|
if (buildingLib) {
|
|
|
|
LibPaths->push_back(HexagonLibDir + MarchG0Suffix);
|
|
|
|
LibPaths->push_back(HexagonLibDir + G0Suffix);
|
|
|
|
}
|
|
|
|
LibPaths->push_back(HexagonLibDir + MarchSuffix);
|
|
|
|
LibPaths->push_back(HexagonLibDir);
|
|
|
|
}
|
|
|
|
|
2012-12-06 20:43:18 +08:00
|
|
|
Hexagon_TC::Hexagon_TC(const Driver &D, const llvm::Triple &Triple,
|
|
|
|
const ArgList &Args)
|
|
|
|
: Linux(D, Triple, Args) {
|
|
|
|
const std::string InstalledDir(getDriver().getInstalledDir());
|
|
|
|
const std::string GnuDir = Hexagon_TC::GetGnuDir(InstalledDir);
|
|
|
|
|
|
|
|
// Note: Generic_GCC::Generic_GCC adds InstalledDir and getDriver().Dir to
|
|
|
|
// program paths
|
|
|
|
const std::string BinDir(GnuDir + "/bin");
|
|
|
|
if (llvm::sys::fs::exists(BinDir))
|
|
|
|
getProgramPaths().push_back(BinDir);
|
|
|
|
|
|
|
|
// Determine version of GCC libraries and headers to use.
|
|
|
|
const std::string HexagonDir(GnuDir + "/lib/gcc/hexagon");
|
|
|
|
llvm::error_code ec;
|
|
|
|
GCCVersion MaxVersion= GCCVersion::Parse("0.0.0");
|
|
|
|
for (llvm::sys::fs::directory_iterator di(HexagonDir, ec), de;
|
|
|
|
!ec && di != de; di = di.increment(ec)) {
|
|
|
|
GCCVersion cv = GCCVersion::Parse(llvm::sys::path::filename(di->path()));
|
|
|
|
if (MaxVersion < cv)
|
|
|
|
MaxVersion = cv;
|
|
|
|
}
|
|
|
|
GCCLibAndIncVersion = MaxVersion;
|
2012-12-06 23:46:07 +08:00
|
|
|
|
|
|
|
ToolChain::path_list *LibPaths= &getFilePaths();
|
|
|
|
|
|
|
|
// Remove paths added by Linux toolchain. Currently Hexagon_TC really targets
|
|
|
|
// 'elf' OS type, so the Linux paths are not appropriate. When we actually
|
|
|
|
// support 'linux' we'll need to fix this up
|
|
|
|
LibPaths->clear();
|
|
|
|
|
|
|
|
GetHexagonLibraryPaths(
|
|
|
|
Args,
|
|
|
|
GetGCCLibAndIncVersion(),
|
|
|
|
GetTargetCPU(Args),
|
|
|
|
InstalledDir,
|
|
|
|
LibPaths);
|
2011-12-13 05:14:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
Hexagon_TC::~Hexagon_TC() {
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Hexagon_TC::buildAssembler() const {
|
|
|
|
return new tools::hexagon::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Hexagon_TC::buildLinker() const {
|
|
|
|
return new tools::hexagon::Link(*this);
|
2011-12-13 05:14:55 +08:00
|
|
|
}
|
|
|
|
|
2012-12-06 20:43:18 +08:00
|
|
|
void Hexagon_TC::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
const Driver &D = getDriver();
|
|
|
|
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdinc) ||
|
|
|
|
DriverArgs.hasArg(options::OPT_nostdlibinc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
llvm::sys::Path InstallDir(D.InstalledDir);
|
|
|
|
std::string Ver(GetGCCLibAndIncVersion());
|
|
|
|
std::string GnuDir = Hexagon_TC::GetGnuDir(D.InstalledDir);
|
|
|
|
std::string HexagonDir(GnuDir + "/lib/gcc/hexagon/" + Ver);
|
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, HexagonDir + "/include");
|
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, HexagonDir + "/include-fixed");
|
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, GnuDir + "/hexagon/include");
|
2011-12-13 05:14:55 +08:00
|
|
|
}
|
|
|
|
|
2012-12-06 20:43:18 +08:00
|
|
|
void Hexagon_TC::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
|
|
|
|
DriverArgs.hasArg(options::OPT_nostdincxx))
|
|
|
|
return;
|
|
|
|
|
|
|
|
const Driver &D = getDriver();
|
|
|
|
std::string Ver(GetGCCLibAndIncVersion());
|
|
|
|
llvm::sys::Path IncludeDir(Hexagon_TC::GetGnuDir(D.InstalledDir));
|
|
|
|
|
|
|
|
IncludeDir.appendComponent("hexagon/include/c++/");
|
|
|
|
IncludeDir.appendComponent(Ver);
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, IncludeDir.str());
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
}
|
2012-12-06 22:16:43 +08:00
|
|
|
|
2012-12-06 23:46:07 +08:00
|
|
|
ToolChain::CXXStdlibType
|
|
|
|
Hexagon_TC::GetCXXStdlibType(const ArgList &Args) const {
|
|
|
|
Arg *A = Args.getLastArg(options::OPT_stdlib_EQ);
|
|
|
|
if (!A)
|
|
|
|
return ToolChain::CST_Libstdcxx;
|
|
|
|
|
|
|
|
StringRef Value = A->getValue();
|
|
|
|
if (Value != "libstdc++") {
|
|
|
|
getDriver().Diag(diag::err_drv_invalid_stdlib_name)
|
|
|
|
<< A->getAsString(Args);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ToolChain::CST_Libstdcxx;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Arg *GetLastHexagonArchArg(const ArgList &Args)
|
2012-12-06 22:16:43 +08:00
|
|
|
{
|
|
|
|
Arg *A = NULL;
|
|
|
|
|
|
|
|
for (ArgList::const_iterator it = Args.begin(), ie = Args.end();
|
|
|
|
it != ie; ++it) {
|
|
|
|
if ((*it)->getOption().matches(options::OPT_march_EQ) ||
|
|
|
|
(*it)->getOption().matches(options::OPT_mcpu_EQ)) {
|
|
|
|
A = *it;
|
|
|
|
A->claim();
|
|
|
|
} else if ((*it)->getOption().matches(options::OPT_m_Joined)) {
|
|
|
|
StringRef Value = (*it)->getValue(0);
|
|
|
|
if (Value.startswith("v")) {
|
|
|
|
A = *it;
|
|
|
|
A->claim();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return A;
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef Hexagon_TC::GetTargetCPU(const ArgList &Args)
|
|
|
|
{
|
|
|
|
// Select the default CPU (v4) if none was given or detection failed.
|
|
|
|
Arg *A = GetLastHexagonArchArg (Args);
|
|
|
|
if (A) {
|
2013-01-13 03:30:44 +08:00
|
|
|
StringRef WhichHexagon = A->getValue();
|
2012-12-06 22:16:43 +08:00
|
|
|
if (WhichHexagon.startswith("hexagon"))
|
|
|
|
return WhichHexagon.substr(sizeof("hexagon") - 1);
|
|
|
|
if (WhichHexagon != "")
|
|
|
|
return WhichHexagon;
|
|
|
|
}
|
|
|
|
|
|
|
|
return "v4";
|
|
|
|
}
|
2012-12-06 20:43:18 +08:00
|
|
|
// End Hexagon
|
2009-03-25 12:13:45 +08:00
|
|
|
|
2010-03-05 05:07:38 +08:00
|
|
|
/// TCEToolChain - A tool chain using the llvm bitcode tools to perform
|
|
|
|
/// all subcommands. See http://tce.cs.tut.fi for our peculiar target.
|
|
|
|
/// Currently does not support anything else but compilation.
|
|
|
|
|
2013-03-19 02:10:27 +08:00
|
|
|
TCEToolChain::TCEToolChain(const Driver &D, const llvm::Triple& Triple,
|
|
|
|
const ArgList &Args)
|
|
|
|
: ToolChain(D, Triple, Args) {
|
2010-03-05 05:07:38 +08:00
|
|
|
// Path mangling to find libexec
|
|
|
|
std::string Path(getDriver().Dir);
|
|
|
|
|
|
|
|
Path += "/../libexec";
|
|
|
|
getProgramPaths().push_back(Path);
|
|
|
|
}
|
|
|
|
|
|
|
|
TCEToolChain::~TCEToolChain() {
|
|
|
|
}
|
|
|
|
|
2011-06-03 11:49:51 +08:00
|
|
|
bool TCEToolChain::IsMathErrnoDefault() const {
|
|
|
|
return true;
|
2010-03-05 05:07:38 +08:00
|
|
|
}
|
|
|
|
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
bool TCEToolChain::isPICDefault() const {
|
|
|
|
return false;
|
2010-03-05 05:07:38 +08:00
|
|
|
}
|
|
|
|
|
2013-04-09 12:35:11 +08:00
|
|
|
bool TCEToolChain::isPIEDefault() const {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Completely re-work how the Clang driver interprets PIC and PIE options.
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
2012-11-19 11:52:03 +08:00
|
|
|
bool TCEToolChain::isPICDefaultForced() const {
|
|
|
|
return false;
|
2010-03-05 05:07:38 +08:00
|
|
|
}
|
|
|
|
|
2009-06-30 04:52:51 +08:00
|
|
|
/// OpenBSD - OpenBSD tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
OpenBSD::OpenBSD(const Driver &D, const llvm::Triple& Triple, const ArgList &Args)
|
|
|
|
: Generic_ELF(D, Triple, Args) {
|
2009-12-22 02:54:17 +08:00
|
|
|
getFilePaths().push_back(getDriver().Dir + "/../lib");
|
2009-06-30 04:52:51 +08:00
|
|
|
getFilePaths().push_back("/usr/lib");
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *OpenBSD::buildAssembler() const {
|
|
|
|
return new tools::openbsd::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *OpenBSD::buildLinker() const {
|
|
|
|
return new tools::openbsd::Link(*this);
|
2009-06-30 04:52:51 +08:00
|
|
|
}
|
|
|
|
|
2012-08-09 07:57:20 +08:00
|
|
|
/// Bitrig - Bitrig tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
|
|
|
Bitrig::Bitrig(const Driver &D, const llvm::Triple& Triple, const ArgList &Args)
|
|
|
|
: Generic_ELF(D, Triple, Args) {
|
|
|
|
getFilePaths().push_back(getDriver().Dir + "/../lib");
|
|
|
|
getFilePaths().push_back("/usr/lib");
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Bitrig::buildAssembler() const {
|
|
|
|
return new tools::bitrig::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Bitrig::buildLinker() const {
|
|
|
|
return new tools::bitrig::Link(*this);
|
2012-08-09 07:57:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void Bitrig::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
|
|
|
|
DriverArgs.hasArg(options::OPT_nostdincxx))
|
|
|
|
return;
|
|
|
|
|
2012-10-09 05:31:38 +08:00
|
|
|
switch (GetCXXStdlibType(DriverArgs)) {
|
|
|
|
case ToolChain::CST_Libcxx:
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
getDriver().SysRoot + "/usr/include/c++/");
|
|
|
|
break;
|
|
|
|
case ToolChain::CST_Libstdcxx:
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
getDriver().SysRoot + "/usr/include/c++/stdc++");
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
getDriver().SysRoot + "/usr/include/c++/stdc++/backward");
|
|
|
|
|
|
|
|
StringRef Triple = getTriple().str();
|
|
|
|
if (Triple.startswith("amd64"))
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
getDriver().SysRoot + "/usr/include/c++/stdc++/x86_64" +
|
|
|
|
Triple.substr(5));
|
|
|
|
else
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
getDriver().SysRoot + "/usr/include/c++/stdc++/" +
|
|
|
|
Triple);
|
|
|
|
break;
|
|
|
|
}
|
2012-08-09 07:57:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void Bitrig::AddCXXStdlibLibArgs(const ArgList &Args,
|
|
|
|
ArgStringList &CmdArgs) const {
|
2012-10-09 05:31:38 +08:00
|
|
|
switch (GetCXXStdlibType(Args)) {
|
|
|
|
case ToolChain::CST_Libcxx:
|
|
|
|
CmdArgs.push_back("-lc++");
|
|
|
|
CmdArgs.push_back("-lcxxrt");
|
|
|
|
// Include supc++ to provide Unwind until provided by libcxx.
|
|
|
|
CmdArgs.push_back("-lgcc");
|
|
|
|
break;
|
|
|
|
case ToolChain::CST_Libstdcxx:
|
|
|
|
CmdArgs.push_back("-lstdc++");
|
|
|
|
break;
|
|
|
|
}
|
2012-08-09 07:57:20 +08:00
|
|
|
}
|
|
|
|
|
2009-03-31 05:06:03 +08:00
|
|
|
/// FreeBSD - FreeBSD tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
FreeBSD::FreeBSD(const Driver &D, const llvm::Triple& Triple, const ArgList &Args)
|
|
|
|
: Generic_ELF(D, Triple, Args) {
|
2010-08-02 13:43:59 +08:00
|
|
|
|
2012-01-26 09:35:15 +08:00
|
|
|
// When targeting 32-bit platforms, look for '/usr/lib32/crt1.o' and fall
|
|
|
|
// back to '/usr/lib' if it doesn't exist.
|
2012-01-25 19:24:24 +08:00
|
|
|
if ((Triple.getArch() == llvm::Triple::x86 ||
|
|
|
|
Triple.getArch() == llvm::Triple::ppc) &&
|
2012-01-26 09:35:15 +08:00
|
|
|
llvm::sys::fs::exists(getDriver().SysRoot + "/usr/lib32/crt1.o"))
|
2012-01-25 19:24:24 +08:00
|
|
|
getFilePaths().push_back(getDriver().SysRoot + "/usr/lib32");
|
|
|
|
else
|
|
|
|
getFilePaths().push_back(getDriver().SysRoot + "/usr/lib");
|
2009-03-31 05:06:03 +08:00
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *FreeBSD::buildAssembler() const {
|
|
|
|
return new tools::freebsd::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *FreeBSD::buildLinker() const {
|
|
|
|
return new tools::freebsd::Link(*this);
|
2011-02-03 02:59:27 +08:00
|
|
|
}
|
|
|
|
|
2012-12-13 12:17:14 +08:00
|
|
|
bool FreeBSD::UseSjLjExceptions() const {
|
|
|
|
// FreeBSD uses SjLj exceptions on ARM oabi.
|
|
|
|
switch (getTriple().getEnvironment()) {
|
|
|
|
case llvm::Triple::GNUEABI:
|
|
|
|
case llvm::Triple::EABI:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return (getTriple().getArch() == llvm::Triple::arm ||
|
|
|
|
getTriple().getArch() == llvm::Triple::thumb);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-03 02:59:27 +08:00
|
|
|
/// NetBSD - NetBSD tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
NetBSD::NetBSD(const Driver &D, const llvm::Triple& Triple, const ArgList &Args)
|
|
|
|
: Generic_ELF(D, Triple, Args) {
|
2011-02-03 02:59:27 +08:00
|
|
|
|
2011-03-21 21:59:26 +08:00
|
|
|
if (getDriver().UseStdLib) {
|
2012-01-25 19:18:20 +08:00
|
|
|
// When targeting a 32-bit platform, try the special directory used on
|
|
|
|
// 64-bit hosts, and only fall back to the main library directory if that
|
|
|
|
// doesn't work.
|
|
|
|
// FIXME: It'd be nicer to test if this directory exists, but I'm not sure
|
|
|
|
// what all logic is needed to emulate the '=' prefix here.
|
2012-01-27 05:58:37 +08:00
|
|
|
if (Triple.getArch() == llvm::Triple::x86)
|
2011-03-21 21:59:26 +08:00
|
|
|
getFilePaths().push_back("=/usr/lib/i386");
|
2012-01-25 19:18:20 +08:00
|
|
|
|
|
|
|
getFilePaths().push_back("=/usr/lib");
|
2011-02-03 02:59:27 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *NetBSD::buildAssembler() const {
|
|
|
|
return new tools::netbsd::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *NetBSD::buildLinker() const {
|
|
|
|
return new tools::netbsd::Link(*this);
|
2009-03-31 05:06:03 +08:00
|
|
|
}
|
2009-05-03 02:28:39 +08:00
|
|
|
|
2010-07-08 00:01:42 +08:00
|
|
|
/// Minix - Minix tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
Minix::Minix(const Driver &D, const llvm::Triple& Triple, const ArgList &Args)
|
|
|
|
: Generic_ELF(D, Triple, Args) {
|
2010-07-08 00:01:42 +08:00
|
|
|
getFilePaths().push_back(getDriver().Dir + "/../lib");
|
|
|
|
getFilePaths().push_back("/usr/lib");
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Minix::buildAssembler() const {
|
|
|
|
return new tools::minix::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Minix::buildLinker() const {
|
|
|
|
return new tools::minix::Link(*this);
|
2010-07-08 00:01:42 +08:00
|
|
|
}
|
|
|
|
|
2009-08-22 09:06:46 +08:00
|
|
|
/// AuroraUX - AuroraUX tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
AuroraUX::AuroraUX(const Driver &D, const llvm::Triple& Triple,
|
|
|
|
const ArgList &Args)
|
|
|
|
: Generic_GCC(D, Triple, Args) {
|
2009-08-22 09:06:46 +08:00
|
|
|
|
2010-08-02 06:29:51 +08:00
|
|
|
getProgramPaths().push_back(getDriver().getInstalledDir());
|
2011-03-02 06:50:47 +08:00
|
|
|
if (getDriver().getInstalledDir() != getDriver().Dir)
|
2010-08-02 06:29:51 +08:00
|
|
|
getProgramPaths().push_back(getDriver().Dir);
|
2009-08-22 09:06:46 +08:00
|
|
|
|
2009-12-22 02:54:17 +08:00
|
|
|
getFilePaths().push_back(getDriver().Dir + "/../lib");
|
2009-08-22 09:06:46 +08:00
|
|
|
getFilePaths().push_back("/usr/lib");
|
|
|
|
getFilePaths().push_back("/usr/sfw/lib");
|
|
|
|
getFilePaths().push_back("/opt/gcc4/lib");
|
2009-10-15 15:44:07 +08:00
|
|
|
getFilePaths().push_back("/opt/gcc4/lib/gcc/i386-pc-solaris2.11/4.2.4");
|
2009-08-22 09:06:46 +08:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *AuroraUX::buildAssembler() const {
|
|
|
|
return new tools::auroraux::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *AuroraUX::buildLinker() const {
|
|
|
|
return new tools::auroraux::Link(*this);
|
2009-08-22 09:06:46 +08:00
|
|
|
}
|
|
|
|
|
2012-02-15 21:39:01 +08:00
|
|
|
/// Solaris - Solaris tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
Solaris::Solaris(const Driver &D, const llvm::Triple& Triple,
|
|
|
|
const ArgList &Args)
|
|
|
|
: Generic_GCC(D, Triple, Args) {
|
2012-02-15 21:39:01 +08:00
|
|
|
|
|
|
|
getProgramPaths().push_back(getDriver().getInstalledDir());
|
|
|
|
if (getDriver().getInstalledDir() != getDriver().Dir)
|
|
|
|
getProgramPaths().push_back(getDriver().Dir);
|
|
|
|
|
|
|
|
getFilePaths().push_back(getDriver().Dir + "/../lib");
|
|
|
|
getFilePaths().push_back("/usr/lib");
|
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Solaris::buildAssembler() const {
|
|
|
|
return new tools::solaris::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Solaris::buildLinker() const {
|
|
|
|
return new tools::solaris::Link(*this);
|
2012-02-15 21:39:01 +08:00
|
|
|
}
|
2009-08-22 09:06:46 +08:00
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
/// Distribution (very bare-bones at the moment).
|
2009-05-26 15:52:18 +08:00
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
enum Distro {
|
2011-02-25 14:39:53 +08:00
|
|
|
ArchLinux,
|
2010-11-08 04:14:31 +08:00
|
|
|
DebianLenny,
|
|
|
|
DebianSqueeze,
|
2011-06-03 05:36:53 +08:00
|
|
|
DebianWheezy,
|
2013-01-06 16:09:29 +08:00
|
|
|
DebianJessie,
|
2010-11-11 10:07:13 +08:00
|
|
|
Exherbo,
|
2011-05-22 13:36:06 +08:00
|
|
|
RHEL4,
|
|
|
|
RHEL5,
|
|
|
|
RHEL6,
|
2010-11-08 04:14:31 +08:00
|
|
|
Fedora13,
|
|
|
|
Fedora14,
|
2011-04-07 02:22:53 +08:00
|
|
|
Fedora15,
|
2012-02-06 23:33:06 +08:00
|
|
|
Fedora16,
|
2011-04-07 02:22:53 +08:00
|
|
|
FedoraRawhide,
|
2010-11-08 04:14:31 +08:00
|
|
|
OpenSuse11_3,
|
2011-05-19 21:26:33 +08:00
|
|
|
OpenSuse11_4,
|
|
|
|
OpenSuse12_1,
|
2012-05-01 07:42:57 +08:00
|
|
|
OpenSuse12_2,
|
2011-03-14 23:39:50 +08:00
|
|
|
UbuntuHardy,
|
|
|
|
UbuntuIntrepid,
|
2010-11-10 13:00:22 +08:00
|
|
|
UbuntuJaunty,
|
2010-11-15 17:01:52 +08:00
|
|
|
UbuntuKarmic,
|
2010-11-08 04:14:31 +08:00
|
|
|
UbuntuLucid,
|
|
|
|
UbuntuMaverick,
|
2011-04-06 06:04:27 +08:00
|
|
|
UbuntuNatty,
|
2011-06-06 00:08:59 +08:00
|
|
|
UbuntuOneiric,
|
2012-02-06 22:36:09 +08:00
|
|
|
UbuntuPrecise,
|
2012-12-14 04:26:05 +08:00
|
|
|
UbuntuQuantal,
|
|
|
|
UbuntuRaring,
|
2010-11-08 04:14:31 +08:00
|
|
|
UnknownDistro
|
|
|
|
};
|
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
static bool IsRedhat(enum Distro Distro) {
|
2012-02-06 23:33:06 +08:00
|
|
|
return (Distro >= Fedora13 && Distro <= FedoraRawhide) ||
|
|
|
|
(Distro >= RHEL4 && Distro <= RHEL6);
|
2010-11-08 04:14:31 +08:00
|
|
|
}
|
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
static bool IsOpenSuse(enum Distro Distro) {
|
2012-05-01 07:42:57 +08:00
|
|
|
return Distro >= OpenSuse11_3 && Distro <= OpenSuse12_2;
|
2010-11-08 04:14:31 +08:00
|
|
|
}
|
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
static bool IsDebian(enum Distro Distro) {
|
2013-01-06 16:09:29 +08:00
|
|
|
return Distro >= DebianLenny && Distro <= DebianJessie;
|
2010-11-08 04:14:31 +08:00
|
|
|
}
|
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
static bool IsUbuntu(enum Distro Distro) {
|
2012-12-14 04:26:05 +08:00
|
|
|
return Distro >= UbuntuHardy && Distro <= UbuntuRaring;
|
2010-11-08 04:14:31 +08:00
|
|
|
}
|
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
static Distro DetectDistro(llvm::Triple::ArchType Arch) {
|
2012-02-05 10:12:40 +08:00
|
|
|
OwningPtr<llvm::MemoryBuffer> File;
|
2010-12-16 11:28:14 +08:00
|
|
|
if (!llvm::MemoryBuffer::getFile("/etc/lsb-release", File)) {
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef Data = File.get()->getBuffer();
|
|
|
|
SmallVector<StringRef, 8> Lines;
|
2010-11-08 04:14:31 +08:00
|
|
|
Data.split(Lines, "\n");
|
2013-03-29 03:02:48 +08:00
|
|
|
Distro Version = UnknownDistro;
|
2012-02-06 22:36:09 +08:00
|
|
|
for (unsigned i = 0, s = Lines.size(); i != s; ++i)
|
|
|
|
if (Version == UnknownDistro && Lines[i].startswith("DISTRIB_CODENAME="))
|
2013-03-29 03:02:48 +08:00
|
|
|
Version = llvm::StringSwitch<Distro>(Lines[i].substr(17))
|
2012-02-06 22:36:09 +08:00
|
|
|
.Case("hardy", UbuntuHardy)
|
|
|
|
.Case("intrepid", UbuntuIntrepid)
|
|
|
|
.Case("jaunty", UbuntuJaunty)
|
|
|
|
.Case("karmic", UbuntuKarmic)
|
|
|
|
.Case("lucid", UbuntuLucid)
|
|
|
|
.Case("maverick", UbuntuMaverick)
|
|
|
|
.Case("natty", UbuntuNatty)
|
|
|
|
.Case("oneiric", UbuntuOneiric)
|
|
|
|
.Case("precise", UbuntuPrecise)
|
2012-12-14 04:26:05 +08:00
|
|
|
.Case("quantal", UbuntuQuantal)
|
|
|
|
.Case("raring", UbuntuRaring)
|
2012-02-06 22:36:09 +08:00
|
|
|
.Default(UnknownDistro);
|
|
|
|
return Version;
|
2010-11-08 04:14:31 +08:00
|
|
|
}
|
|
|
|
|
2010-12-16 11:28:14 +08:00
|
|
|
if (!llvm::MemoryBuffer::getFile("/etc/redhat-release", File)) {
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef Data = File.get()->getBuffer();
|
2012-02-06 23:33:06 +08:00
|
|
|
if (Data.startswith("Fedora release 16"))
|
|
|
|
return Fedora16;
|
|
|
|
else if (Data.startswith("Fedora release 15"))
|
2011-04-07 02:22:53 +08:00
|
|
|
return Fedora15;
|
|
|
|
else if (Data.startswith("Fedora release 14"))
|
2010-11-08 04:14:31 +08:00
|
|
|
return Fedora14;
|
2011-04-07 02:22:53 +08:00
|
|
|
else if (Data.startswith("Fedora release 13"))
|
2010-11-08 04:14:31 +08:00
|
|
|
return Fedora13;
|
2011-04-07 02:22:53 +08:00
|
|
|
else if (Data.startswith("Fedora release") &&
|
2011-07-23 18:55:15 +08:00
|
|
|
Data.find("Rawhide") != StringRef::npos)
|
2011-04-07 02:22:53 +08:00
|
|
|
return FedoraRawhide;
|
2011-05-22 13:36:06 +08:00
|
|
|
else if (Data.startswith("Red Hat Enterprise Linux") &&
|
2011-07-23 18:55:15 +08:00
|
|
|
Data.find("release 6") != StringRef::npos)
|
2011-05-22 13:36:06 +08:00
|
|
|
return RHEL6;
|
2011-06-03 23:23:24 +08:00
|
|
|
else if ((Data.startswith("Red Hat Enterprise Linux") ||
|
2013-02-05 15:29:49 +08:00
|
|
|
Data.startswith("CentOS")) &&
|
2011-07-23 18:55:15 +08:00
|
|
|
Data.find("release 5") != StringRef::npos)
|
2011-05-22 13:36:06 +08:00
|
|
|
return RHEL5;
|
2011-06-03 23:23:24 +08:00
|
|
|
else if ((Data.startswith("Red Hat Enterprise Linux") ||
|
2013-02-05 15:29:49 +08:00
|
|
|
Data.startswith("CentOS")) &&
|
2011-07-23 18:55:15 +08:00
|
|
|
Data.find("release 4") != StringRef::npos)
|
2011-05-22 13:36:06 +08:00
|
|
|
return RHEL4;
|
2010-11-08 04:14:31 +08:00
|
|
|
return UnknownDistro;
|
|
|
|
}
|
|
|
|
|
2010-12-16 11:28:14 +08:00
|
|
|
if (!llvm::MemoryBuffer::getFile("/etc/debian_version", File)) {
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef Data = File.get()->getBuffer();
|
2010-11-08 04:14:31 +08:00
|
|
|
if (Data[0] == '5')
|
|
|
|
return DebianLenny;
|
2011-12-29 02:17:14 +08:00
|
|
|
else if (Data.startswith("squeeze/sid") || Data[0] == '6')
|
2010-11-08 04:14:31 +08:00
|
|
|
return DebianSqueeze;
|
2011-12-29 02:17:14 +08:00
|
|
|
else if (Data.startswith("wheezy/sid") || Data[0] == '7')
|
2011-06-03 05:36:53 +08:00
|
|
|
return DebianWheezy;
|
2013-01-06 16:09:29 +08:00
|
|
|
else if (Data.startswith("jessie/sid") || Data[0] == '8')
|
|
|
|
return DebianJessie;
|
2010-11-08 04:14:31 +08:00
|
|
|
return UnknownDistro;
|
|
|
|
}
|
|
|
|
|
2012-02-06 23:33:06 +08:00
|
|
|
if (!llvm::MemoryBuffer::getFile("/etc/SuSE-release", File))
|
2013-03-29 03:02:48 +08:00
|
|
|
return llvm::StringSwitch<Distro>(File.get()->getBuffer())
|
2012-02-06 23:33:06 +08:00
|
|
|
.StartsWith("openSUSE 11.3", OpenSuse11_3)
|
|
|
|
.StartsWith("openSUSE 11.4", OpenSuse11_4)
|
|
|
|
.StartsWith("openSUSE 12.1", OpenSuse12_1)
|
2012-05-01 07:42:57 +08:00
|
|
|
.StartsWith("openSUSE 12.2", OpenSuse12_2)
|
2012-02-06 23:33:06 +08:00
|
|
|
.Default(UnknownDistro);
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2011-01-10 10:34:13 +08:00
|
|
|
bool Exists;
|
|
|
|
if (!llvm::sys::fs::exists("/etc/exherbo-release", Exists) && Exists)
|
2010-11-11 10:07:13 +08:00
|
|
|
return Exherbo;
|
|
|
|
|
2011-02-25 14:39:53 +08:00
|
|
|
if (!llvm::sys::fs::exists("/etc/arch-release", Exists) && Exists)
|
|
|
|
return ArchLinux;
|
|
|
|
|
2010-11-08 04:14:31 +08:00
|
|
|
return UnknownDistro;
|
|
|
|
}
|
|
|
|
|
2011-10-31 16:42:24 +08:00
|
|
|
/// \brief Get our best guess at the multiarch triple for a target.
|
|
|
|
///
|
|
|
|
/// Debian-based systems are starting to use a multiarch setup where they use
|
|
|
|
/// a target-triple directory in the library and header search paths.
|
|
|
|
/// Unfortunately, this triple does not align with the vanilla target triple,
|
|
|
|
/// so we provide a rough mapping here.
|
|
|
|
static std::string getMultiarchTriple(const llvm::Triple TargetTriple,
|
|
|
|
StringRef SysRoot) {
|
|
|
|
// For most architectures, just use whatever we have rather than trying to be
|
|
|
|
// clever.
|
|
|
|
switch (TargetTriple.getArch()) {
|
|
|
|
default:
|
|
|
|
return TargetTriple.str();
|
|
|
|
|
|
|
|
// We use the existence of '/lib/<triple>' as a directory to detect some
|
|
|
|
// common linux triples that don't quite match the Clang triple for both
|
2011-10-31 17:06:40 +08:00
|
|
|
// 32-bit and 64-bit targets. Multiarch fixes its install triples to these
|
|
|
|
// regardless of what the actual target triple is.
|
2012-07-12 03:08:21 +08:00
|
|
|
case llvm::Triple::arm:
|
|
|
|
case llvm::Triple::thumb:
|
2012-07-31 16:06:29 +08:00
|
|
|
if (TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF) {
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/arm-linux-gnueabihf"))
|
|
|
|
return "arm-linux-gnueabihf";
|
|
|
|
} else {
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/arm-linux-gnueabi"))
|
|
|
|
return "arm-linux-gnueabi";
|
|
|
|
}
|
2012-07-12 03:08:21 +08:00
|
|
|
return TargetTriple.str();
|
2011-10-31 16:42:24 +08:00
|
|
|
case llvm::Triple::x86:
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/i386-linux-gnu"))
|
|
|
|
return "i386-linux-gnu";
|
|
|
|
return TargetTriple.str();
|
|
|
|
case llvm::Triple::x86_64:
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/x86_64-linux-gnu"))
|
|
|
|
return "x86_64-linux-gnu";
|
|
|
|
return TargetTriple.str();
|
2013-01-31 20:13:10 +08:00
|
|
|
case llvm::Triple::aarch64:
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/aarch64-linux-gnu"))
|
|
|
|
return "aarch64-linux-gnu";
|
2011-11-09 03:43:37 +08:00
|
|
|
case llvm::Triple::mips:
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/mips-linux-gnu"))
|
|
|
|
return "mips-linux-gnu";
|
|
|
|
return TargetTriple.str();
|
|
|
|
case llvm::Triple::mipsel:
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/mipsel-linux-gnu"))
|
|
|
|
return "mipsel-linux-gnu";
|
|
|
|
return TargetTriple.str();
|
2012-02-26 17:03:21 +08:00
|
|
|
case llvm::Triple::ppc:
|
2013-03-16 00:22:43 +08:00
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/powerpc-linux-gnuspe"))
|
|
|
|
return "powerpc-linux-gnuspe";
|
2012-02-26 17:03:21 +08:00
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/powerpc-linux-gnu"))
|
|
|
|
return "powerpc-linux-gnu";
|
|
|
|
return TargetTriple.str();
|
|
|
|
case llvm::Triple::ppc64:
|
|
|
|
if (llvm::sys::fs::exists(SysRoot + "/lib/powerpc64-linux-gnu"))
|
|
|
|
return "powerpc64-linux-gnu";
|
|
|
|
return TargetTriple.str();
|
2011-10-31 16:42:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-25 19:24:24 +08:00
|
|
|
static void addPathIfExists(Twine Path, ToolChain::path_list &Paths) {
|
|
|
|
if (llvm::sys::fs::exists(Path)) Paths.push_back(Path.str());
|
|
|
|
}
|
|
|
|
|
2012-10-04 01:46:38 +08:00
|
|
|
static bool isMipsR2Arch(llvm::Triple::ArchType Arch,
|
|
|
|
const ArgList &Args) {
|
|
|
|
if (Arch != llvm::Triple::mips &&
|
|
|
|
Arch != llvm::Triple::mipsel)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
Arg *A = Args.getLastArg(options::OPT_march_EQ,
|
|
|
|
options::OPT_mcpu_EQ,
|
|
|
|
options::OPT_mips_CPUs_Group);
|
|
|
|
|
|
|
|
if (!A)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (A->getOption().matches(options::OPT_mips_CPUs_Group))
|
|
|
|
return A->getOption().matches(options::OPT_mips32r2);
|
|
|
|
|
2012-11-01 12:30:05 +08:00
|
|
|
return A->getValue() == StringRef("mips32r2");
|
2012-10-04 01:46:38 +08:00
|
|
|
}
|
|
|
|
|
2012-09-14 19:27:24 +08:00
|
|
|
static StringRef getMultilibDir(const llvm::Triple &Triple,
|
|
|
|
const ArgList &Args) {
|
|
|
|
if (!isMipsArch(Triple.getArch()))
|
|
|
|
return Triple.isArch32Bit() ? "lib32" : "lib64";
|
|
|
|
|
|
|
|
// lib32 directory has a special meaning on MIPS targets.
|
|
|
|
// It contains N32 ABI binaries. Use this folder if produce
|
|
|
|
// code for N32 ABI only.
|
2012-10-21 19:44:57 +08:00
|
|
|
if (hasMipsN32ABIArg(Args))
|
2012-09-14 19:27:24 +08:00
|
|
|
return "lib32";
|
|
|
|
|
|
|
|
return Triple.isArch32Bit() ? "lib" : "lib64";
|
|
|
|
}
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
Linux::Linux(const Driver &D, const llvm::Triple &Triple, const ArgList &Args)
|
|
|
|
: Generic_ELF(D, Triple, Args) {
|
2012-01-25 04:08:17 +08:00
|
|
|
llvm::Triple::ArchType Arch = Triple.getArch();
|
2013-04-20 16:15:03 +08:00
|
|
|
std::string SysRoot = computeSysRoot(Args);
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2011-09-02 00:25:49 +08:00
|
|
|
// OpenSuse stores the linker with the compiler, add that to the search
|
|
|
|
// path.
|
|
|
|
ToolChain::path_list &PPaths = getProgramPaths();
|
2011-11-06 17:21:54 +08:00
|
|
|
PPaths.push_back(Twine(GCCInstallation.getParentLibPath() + "/../" +
|
2012-01-25 03:28:29 +08:00
|
|
|
GCCInstallation.getTriple().str() + "/bin").str());
|
2011-09-02 00:25:49 +08:00
|
|
|
|
|
|
|
Linker = GetProgramPath("ld");
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2013-03-29 03:02:48 +08:00
|
|
|
Distro Distro = DetectDistro(Arch);
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2011-05-23 00:45:07 +08:00
|
|
|
if (IsOpenSuse(Distro) || IsUbuntu(Distro)) {
|
2010-11-08 22:48:47 +08:00
|
|
|
ExtraOpts.push_back("-z");
|
|
|
|
ExtraOpts.push_back("relro");
|
|
|
|
}
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2011-03-07 03:11:49 +08:00
|
|
|
if (Arch == llvm::Triple::arm || Arch == llvm::Triple::thumb)
|
2010-11-08 04:14:31 +08:00
|
|
|
ExtraOpts.push_back("-X");
|
|
|
|
|
2012-09-02 17:30:11 +08:00
|
|
|
const bool IsAndroid = Triple.getEnvironment() == llvm::Triple::Android;
|
2013-04-20 16:15:03 +08:00
|
|
|
const bool IsMips = isMipsArch(Arch);
|
|
|
|
|
|
|
|
if (IsMips && !SysRoot.empty())
|
|
|
|
ExtraOpts.push_back("--sysroot=" + SysRoot);
|
2012-01-13 17:30:38 +08:00
|
|
|
|
2011-12-09 12:45:18 +08:00
|
|
|
// Do not use 'gnu' hash style for Mips targets because .gnu.hash
|
|
|
|
// and the MIPS ABI require .dynsym to be sorted in different ways.
|
|
|
|
// .gnu.hash needs symbols to be grouped by hash code whereas the MIPS
|
|
|
|
// ABI requires a mapping between the GOT and the symbol table.
|
2012-01-13 17:30:38 +08:00
|
|
|
// Android loader does not support .gnu.hash.
|
2013-04-20 16:15:03 +08:00
|
|
|
if (!IsMips && !IsAndroid) {
|
2012-02-06 22:36:09 +08:00
|
|
|
if (IsRedhat(Distro) || IsOpenSuse(Distro) ||
|
|
|
|
(IsUbuntu(Distro) && Distro >= UbuntuMaverick))
|
2011-12-09 12:45:18 +08:00
|
|
|
ExtraOpts.push_back("--hash-style=gnu");
|
|
|
|
|
|
|
|
if (IsDebian(Distro) || IsOpenSuse(Distro) || Distro == UbuntuLucid ||
|
|
|
|
Distro == UbuntuJaunty || Distro == UbuntuKarmic)
|
|
|
|
ExtraOpts.push_back("--hash-style=both");
|
|
|
|
}
|
2010-11-08 04:14:31 +08:00
|
|
|
|
2011-05-22 13:36:06 +08:00
|
|
|
if (IsRedhat(Distro))
|
2010-11-08 04:14:31 +08:00
|
|
|
ExtraOpts.push_back("--no-add-needed");
|
|
|
|
|
2011-06-03 05:36:53 +08:00
|
|
|
if (Distro == DebianSqueeze || Distro == DebianWheezy ||
|
2013-01-06 16:09:29 +08:00
|
|
|
Distro == DebianJessie || IsOpenSuse(Distro) ||
|
2011-06-03 23:23:24 +08:00
|
|
|
(IsRedhat(Distro) && Distro != RHEL4 && Distro != RHEL5) ||
|
2012-02-06 22:36:09 +08:00
|
|
|
(IsUbuntu(Distro) && Distro >= UbuntuKarmic))
|
2010-11-08 04:14:31 +08:00
|
|
|
ExtraOpts.push_back("--build-id");
|
|
|
|
|
2011-05-23 00:45:07 +08:00
|
|
|
if (IsOpenSuse(Distro))
|
2011-05-24 15:51:17 +08:00
|
|
|
ExtraOpts.push_back("--enable-new-dtags");
|
2011-05-23 00:45:07 +08:00
|
|
|
|
Rework the selection of builtin library search paths on Linux to
precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.
This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.
There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.
If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.
No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.
llvm-svn: 140981
2011-10-03 13:28:29 +08:00
|
|
|
// The selection of paths to try here is designed to match the patterns which
|
|
|
|
// the GCC driver itself uses, as this is part of the GCC-compatible driver.
|
|
|
|
// This was determined by running GCC in a fake filesystem, creating all
|
|
|
|
// possible permutations of these directories, and seeing which ones it added
|
|
|
|
// to the link paths.
|
|
|
|
path_list &Paths = getFilePaths();
|
2012-01-25 04:08:17 +08:00
|
|
|
|
2012-09-14 19:27:24 +08:00
|
|
|
const std::string Multilib = getMultilibDir(Triple, Args);
|
2011-10-31 16:42:24 +08:00
|
|
|
const std::string MultiarchTriple = getMultiarchTriple(Triple, SysRoot);
|
2011-02-25 14:39:53 +08:00
|
|
|
|
2011-11-07 07:09:05 +08:00
|
|
|
// Add the multilib suffixed paths where they are available.
|
|
|
|
if (GCCInstallation.isValid()) {
|
2012-01-25 03:28:29 +08:00
|
|
|
const llvm::Triple &GCCTriple = GCCInstallation.getTriple();
|
2012-01-25 04:08:17 +08:00
|
|
|
const std::string &LibPath = GCCInstallation.getParentLibPath();
|
2012-10-04 01:46:38 +08:00
|
|
|
|
|
|
|
if (IsAndroid && isMipsR2Arch(Triple.getArch(), Args))
|
|
|
|
addPathIfExists(GCCInstallation.getInstallPath() +
|
|
|
|
GCCInstallation.getMultiarchSuffix() +
|
|
|
|
"/mips-r2",
|
|
|
|
Paths);
|
|
|
|
else
|
|
|
|
addPathIfExists((GCCInstallation.getInstallPath() +
|
|
|
|
GCCInstallation.getMultiarchSuffix()),
|
|
|
|
Paths);
|
Fix using Clang as a cross compiler installed on a host machine and not
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.
The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.
Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.
This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.
llvm-svn: 154176
2012-04-07 00:32:06 +08:00
|
|
|
|
|
|
|
// If the GCC installation we found is inside of the sysroot, we want to
|
|
|
|
// prefer libraries installed in the parent prefix of the GCC installation.
|
|
|
|
// It is important to *not* use these paths when the GCC installation is
|
2012-04-18 18:59:08 +08:00
|
|
|
// outside of the system root as that can pick up unintended libraries.
|
Fix using Clang as a cross compiler installed on a host machine and not
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.
The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.
Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.
This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.
llvm-svn: 154176
2012-04-07 00:32:06 +08:00
|
|
|
// This usually happens when there is an external cross compiler on the
|
|
|
|
// host system, and a more minimal sysroot available that is the target of
|
|
|
|
// the cross.
|
|
|
|
if (StringRef(LibPath).startswith(SysRoot)) {
|
|
|
|
addPathIfExists(LibPath + "/../" + GCCTriple.str() + "/lib/../" + Multilib,
|
|
|
|
Paths);
|
|
|
|
addPathIfExists(LibPath + "/" + MultiarchTriple, Paths);
|
|
|
|
addPathIfExists(LibPath + "/../" + Multilib, Paths);
|
|
|
|
}
|
2012-09-03 17:05:50 +08:00
|
|
|
// On Android, libraries in the parent prefix of the GCC installation are
|
|
|
|
// preferred to the ones under sysroot.
|
|
|
|
if (IsAndroid) {
|
|
|
|
addPathIfExists(LibPath + "/../" + GCCTriple.str() + "/lib", Paths);
|
|
|
|
}
|
2013-04-20 16:15:03 +08:00
|
|
|
// Sourcery CodeBench MIPS toolchain holds some libraries under
|
|
|
|
// the parent prefix of the GCC installation.
|
|
|
|
if (IsMips) {
|
|
|
|
SmallString<128> Suffix;
|
|
|
|
appendMipsTargetSuffix(Suffix, Arch, Args);
|
|
|
|
addPathIfExists(LibPath + "/../" + GCCTriple.str() + "/lib/../" +
|
|
|
|
Multilib + Suffix.str(),
|
|
|
|
Paths);
|
|
|
|
}
|
2010-11-08 04:14:31 +08:00
|
|
|
}
|
2011-11-07 07:09:05 +08:00
|
|
|
addPathIfExists(SysRoot + "/lib/" + MultiarchTriple, Paths);
|
|
|
|
addPathIfExists(SysRoot + "/lib/../" + Multilib, Paths);
|
|
|
|
addPathIfExists(SysRoot + "/usr/lib/" + MultiarchTriple, Paths);
|
|
|
|
addPathIfExists(SysRoot + "/usr/lib/../" + Multilib, Paths);
|
|
|
|
|
|
|
|
// Try walking via the GCC triple path in case of multiarch GCC
|
|
|
|
// installations with strange symlinks.
|
|
|
|
if (GCCInstallation.isValid())
|
2012-01-25 03:28:29 +08:00
|
|
|
addPathIfExists(SysRoot + "/usr/lib/" + GCCInstallation.getTriple().str() +
|
2011-11-07 07:09:05 +08:00
|
|
|
"/../../" + Multilib, Paths);
|
2011-06-03 23:39:42 +08:00
|
|
|
|
2011-10-16 18:54:30 +08:00
|
|
|
// Add the non-multilib suffixed paths (if potentially different).
|
2011-10-04 02:16:54 +08:00
|
|
|
if (GCCInstallation.isValid()) {
|
|
|
|
const std::string &LibPath = GCCInstallation.getParentLibPath();
|
2012-01-25 03:28:29 +08:00
|
|
|
const llvm::Triple &GCCTriple = GCCInstallation.getTriple();
|
Make a major refactoring to how the GCC installation detection works.
The fundamental shift here is to stop making *any* assumptions about the
*host* triple. Where these assumptions you ask? Why, they were in one of
the two target triples referenced of course. This was the single biggest
place where the previously named "host triple" was actually used as
such. ;] The reason we were reasoning about the host is in order to
detect the use of '-m32' or '-m64' flags to change the target. These
flags shift the default target only slightly, which typically means
a slight deviation from the host. When using these flags, the GCC
installation is under a different triple from the one actually targeted
in the compilation, and we used the host triple to find it.
Too bad that wasn't even correct. Consider an x86 Linux host which has
a PPC64 cross-compiling GCC toolchain installed. This toolchain is also
configured for multiarch compiling and can target PPC32 with eth '-m32'
flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we
have to look for the PPC64 variant of the triple to find the GCC
install, and that triple is neither the host nor target.
The new logic computes the multiarch's alternate triple from the target
triple, and looks under both sides. It also looks more aggressively for
the correct subdirectory of the GCC installation, and exposes the
subdirectory in a nice programmatic way. This '/32' or '/64' suffix is
something we can reuse in many other parts of the toolchain.
An important note -- while this likely fixes a large category of
cross-compile use cases, that's not my primary goal, and I've not done
testing (or added test cases) for scenarios that may now work. If
someone else wants to try more interesting PPC cross compiles, I'd love
to have reports. But my focus is on factoring away the references to the
"host" triple. The refactoring is my goal, and so I'm mostly relying on
the existing (pretty good) test coverage we have here.
Future patches will leverage this new functionality to factor out more
and more of the toolchain's triple manipulation.
llvm-svn: 148935
2012-01-25 15:21:38 +08:00
|
|
|
if (!GCCInstallation.getMultiarchSuffix().empty())
|
2011-10-04 02:16:54 +08:00
|
|
|
addPathIfExists(GCCInstallation.getInstallPath(), Paths);
|
Fix using Clang as a cross compiler installed on a host machine and not
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.
The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.
Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.
This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.
llvm-svn: 154176
2012-04-07 00:32:06 +08:00
|
|
|
|
|
|
|
if (StringRef(LibPath).startswith(SysRoot)) {
|
|
|
|
addPathIfExists(LibPath + "/../" + GCCTriple.str() + "/lib", Paths);
|
|
|
|
addPathIfExists(LibPath, Paths);
|
|
|
|
}
|
Rework the selection of builtin library search paths on Linux to
precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.
This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.
There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.
If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.
No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.
llvm-svn: 140981
2011-10-03 13:28:29 +08:00
|
|
|
}
|
2011-10-03 14:41:08 +08:00
|
|
|
addPathIfExists(SysRoot + "/lib", Paths);
|
|
|
|
addPathIfExists(SysRoot + "/usr/lib", Paths);
|
2013-04-09 12:35:11 +08:00
|
|
|
|
|
|
|
IsPIEDefault = SanitizerArgs(*this, Args).hasZeroBaseShadow();
|
2010-11-08 04:14:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Linux::HasNativeLLVMSupport() const {
|
|
|
|
return true;
|
2009-05-26 15:52:18 +08:00
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *Linux::buildLinker() const {
|
2013-03-29 03:04:25 +08:00
|
|
|
return new tools::gnutools::Link(*this);
|
2013-03-20 11:05:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
Tool *Linux::buildAssembler() const {
|
2013-03-29 03:04:25 +08:00
|
|
|
return new tools::gnutools::Assemble(*this);
|
2010-08-10 08:25:48 +08:00
|
|
|
}
|
|
|
|
|
2012-11-22 07:40:23 +08:00
|
|
|
void Linux::addClangTargetOptions(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
2012-06-19 09:26:10 +08:00
|
|
|
const Generic_GCC::GCCVersion &V = GCCInstallation.getVersion();
|
2012-11-22 07:40:23 +08:00
|
|
|
bool UseInitArrayDefault
|
|
|
|
= V >= Generic_GCC::GCCVersion::Parse("4.7.0") ||
|
2013-01-31 20:13:10 +08:00
|
|
|
getTriple().getArch() == llvm::Triple::aarch64 ||
|
2012-11-22 07:40:23 +08:00
|
|
|
getTriple().getEnvironment() == llvm::Triple::Android;
|
|
|
|
if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
|
|
|
|
options::OPT_fno_use_init_array,
|
|
|
|
UseInitArrayDefault))
|
2012-06-19 09:26:10 +08:00
|
|
|
CC1Args.push_back("-fuse-init-array");
|
|
|
|
}
|
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
std::string Linux::computeSysRoot(const ArgList &Args) const {
|
|
|
|
if (!getDriver().SysRoot.empty())
|
|
|
|
return getDriver().SysRoot;
|
|
|
|
|
|
|
|
if (!GCCInstallation.isValid() || !isMipsArch(getTriple().getArch()))
|
|
|
|
return std::string();
|
|
|
|
|
|
|
|
SmallString<128> Path;
|
|
|
|
llvm::sys::path::append(Path, GCCInstallation.getInstallPath(),
|
|
|
|
"../../../..",
|
|
|
|
GCCInstallation.getTriple().str(),
|
|
|
|
"libc");
|
|
|
|
appendMipsTargetSuffix(Path, getTriple().getArch(), Args);
|
|
|
|
|
|
|
|
return llvm::sys::fs::exists(Path.str()) ? Path.str() : "";
|
|
|
|
}
|
|
|
|
|
2011-11-06 04:17:13 +08:00
|
|
|
void Linux::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
const Driver &D = getDriver();
|
2013-04-20 16:15:03 +08:00
|
|
|
std::string SysRoot = computeSysRoot(DriverArgs);
|
2011-11-06 04:17:13 +08:00
|
|
|
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdinc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!DriverArgs.hasArg(options::OPT_nostdlibinc))
|
2013-04-20 16:15:03 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/local/include");
|
2011-11-06 04:17:13 +08:00
|
|
|
|
|
|
|
if (!DriverArgs.hasArg(options::OPT_nobuiltininc)) {
|
|
|
|
llvm::sys::Path P(D.ResourceDir);
|
|
|
|
P.appendComponent("include");
|
2011-11-07 17:17:31 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, P.str());
|
2011-11-06 04:17:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdlibinc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Check for configure-time C include directories.
|
|
|
|
StringRef CIncludeDirs(C_INCLUDE_DIRS);
|
|
|
|
if (CIncludeDirs != "") {
|
|
|
|
SmallVector<StringRef, 5> dirs;
|
|
|
|
CIncludeDirs.split(dirs, ":");
|
|
|
|
for (SmallVectorImpl<StringRef>::iterator I = dirs.begin(), E = dirs.end();
|
|
|
|
I != E; ++I) {
|
2013-04-20 16:15:03 +08:00
|
|
|
StringRef Prefix = llvm::sys::path::is_absolute(*I) ? SysRoot : "";
|
2011-11-06 04:17:13 +08:00
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, Prefix + *I);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Lacking those, try to detect the correct set of system includes for the
|
|
|
|
// target triple.
|
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
// Sourcery CodeBench and modern FSF Mips toolchains put extern C
|
|
|
|
// system includes under three additional directories.
|
|
|
|
if (GCCInstallation.isValid() && isMipsArch(getTriple().getArch())) {
|
|
|
|
addExternCSystemIncludeIfExists(DriverArgs, CC1Args,
|
|
|
|
GCCInstallation.getInstallPath() +
|
|
|
|
"/include");
|
|
|
|
|
|
|
|
addExternCSystemIncludeIfExists(DriverArgs, CC1Args,
|
|
|
|
GCCInstallation.getInstallPath() +
|
|
|
|
"/../../../../" +
|
|
|
|
GCCInstallation.getTriple().str() +
|
|
|
|
"/libc/usr/include");
|
|
|
|
}
|
|
|
|
|
2011-11-06 16:21:07 +08:00
|
|
|
// Implement generic Debian multiarch support.
|
|
|
|
const StringRef X86_64MultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/x86_64-linux-gnu",
|
|
|
|
|
|
|
|
// FIXME: These are older forms of multiarch. It's not clear that they're
|
|
|
|
// in use in any released version of Debian, so we should consider
|
|
|
|
// removing them.
|
|
|
|
"/usr/include/i686-linux-gnu/64",
|
|
|
|
"/usr/include/i486-linux-gnu/64"
|
|
|
|
};
|
|
|
|
const StringRef X86MultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/i386-linux-gnu",
|
|
|
|
|
|
|
|
// FIXME: These are older forms of multiarch. It's not clear that they're
|
|
|
|
// in use in any released version of Debian, so we should consider
|
|
|
|
// removing them.
|
|
|
|
"/usr/include/x86_64-linux-gnu/32",
|
|
|
|
"/usr/include/i686-linux-gnu",
|
|
|
|
"/usr/include/i486-linux-gnu"
|
|
|
|
};
|
2013-01-31 20:13:10 +08:00
|
|
|
const StringRef AArch64MultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/aarch64-linux-gnu"
|
|
|
|
};
|
2011-11-06 16:21:07 +08:00
|
|
|
const StringRef ARMMultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/arm-linux-gnueabi"
|
|
|
|
};
|
2012-07-31 16:06:29 +08:00
|
|
|
const StringRef ARMHFMultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/arm-linux-gnueabihf"
|
|
|
|
};
|
2011-11-11 11:05:19 +08:00
|
|
|
const StringRef MIPSMultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/mips-linux-gnu"
|
|
|
|
};
|
|
|
|
const StringRef MIPSELMultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/mipsel-linux-gnu"
|
|
|
|
};
|
2012-02-26 17:21:43 +08:00
|
|
|
const StringRef PPCMultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/powerpc-linux-gnu"
|
|
|
|
};
|
|
|
|
const StringRef PPC64MultiarchIncludeDirs[] = {
|
|
|
|
"/usr/include/powerpc64-linux-gnu"
|
|
|
|
};
|
2011-11-06 16:21:07 +08:00
|
|
|
ArrayRef<StringRef> MultiarchIncludeDirs;
|
2011-11-06 04:17:13 +08:00
|
|
|
if (getTriple().getArch() == llvm::Triple::x86_64) {
|
2011-11-06 16:21:07 +08:00
|
|
|
MultiarchIncludeDirs = X86_64MultiarchIncludeDirs;
|
2011-11-06 04:17:13 +08:00
|
|
|
} else if (getTriple().getArch() == llvm::Triple::x86) {
|
2011-11-06 16:21:07 +08:00
|
|
|
MultiarchIncludeDirs = X86MultiarchIncludeDirs;
|
2013-01-31 20:13:10 +08:00
|
|
|
} else if (getTriple().getArch() == llvm::Triple::aarch64) {
|
|
|
|
MultiarchIncludeDirs = AArch64MultiarchIncludeDirs;
|
2011-11-06 04:17:13 +08:00
|
|
|
} else if (getTriple().getArch() == llvm::Triple::arm) {
|
2012-07-31 16:06:29 +08:00
|
|
|
if (getTriple().getEnvironment() == llvm::Triple::GNUEABIHF)
|
|
|
|
MultiarchIncludeDirs = ARMHFMultiarchIncludeDirs;
|
|
|
|
else
|
|
|
|
MultiarchIncludeDirs = ARMMultiarchIncludeDirs;
|
2011-11-11 11:05:19 +08:00
|
|
|
} else if (getTriple().getArch() == llvm::Triple::mips) {
|
|
|
|
MultiarchIncludeDirs = MIPSMultiarchIncludeDirs;
|
|
|
|
} else if (getTriple().getArch() == llvm::Triple::mipsel) {
|
|
|
|
MultiarchIncludeDirs = MIPSELMultiarchIncludeDirs;
|
2012-02-26 17:21:43 +08:00
|
|
|
} else if (getTriple().getArch() == llvm::Triple::ppc) {
|
|
|
|
MultiarchIncludeDirs = PPCMultiarchIncludeDirs;
|
|
|
|
} else if (getTriple().getArch() == llvm::Triple::ppc64) {
|
|
|
|
MultiarchIncludeDirs = PPC64MultiarchIncludeDirs;
|
2011-11-06 16:21:07 +08:00
|
|
|
}
|
|
|
|
for (ArrayRef<StringRef>::iterator I = MultiarchIncludeDirs.begin(),
|
|
|
|
E = MultiarchIncludeDirs.end();
|
|
|
|
I != E; ++I) {
|
2013-04-20 16:15:03 +08:00
|
|
|
if (llvm::sys::fs::exists(SysRoot + *I)) {
|
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + *I);
|
2011-11-06 16:21:07 +08:00
|
|
|
break;
|
|
|
|
}
|
2011-11-06 04:17:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (getTriple().getOS() == llvm::Triple::RTEMS)
|
|
|
|
return;
|
|
|
|
|
2011-11-09 01:19:47 +08:00
|
|
|
// Add an include of '/include' directly. This isn't provided by default by
|
|
|
|
// system GCCs, but is often used with cross-compiling GCCs, and harmless to
|
|
|
|
// add even when Clang is acting as-if it were a system compiler.
|
2013-04-20 16:15:03 +08:00
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/include");
|
2011-11-09 01:19:47 +08:00
|
|
|
|
2013-04-20 16:15:03 +08:00
|
|
|
addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include");
|
2011-11-06 04:17:13 +08:00
|
|
|
}
|
|
|
|
|
2013-03-07 01:14:05 +08:00
|
|
|
/// \brief Helper to add the three variant paths for a libstdc++ installation.
|
2011-12-18 07:10:01 +08:00
|
|
|
/*static*/ bool Linux::addLibStdCXXIncludePaths(Twine Base, Twine TargetArchDir,
|
|
|
|
const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) {
|
2011-11-06 18:31:01 +08:00
|
|
|
if (!llvm::sys::fs::exists(Base))
|
|
|
|
return false;
|
2011-11-06 04:17:13 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, Base);
|
2011-11-06 18:31:01 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, Base + "/" + TargetArchDir);
|
2011-11-06 04:17:13 +08:00
|
|
|
addSystemInclude(DriverArgs, CC1Args, Base + "/backward");
|
2011-11-06 18:31:01 +08:00
|
|
|
return true;
|
2011-11-06 04:17:13 +08:00
|
|
|
}
|
|
|
|
|
2013-03-07 01:14:05 +08:00
|
|
|
/// \brief Helper to add an extra variant path for an (Ubuntu) multilib
|
|
|
|
/// libstdc++ installation.
|
|
|
|
/*static*/ bool Linux::addLibStdCXXIncludePaths(Twine Base, Twine Suffix,
|
|
|
|
Twine TargetArchDir,
|
|
|
|
Twine MultiLibSuffix,
|
|
|
|
const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) {
|
|
|
|
if (!addLibStdCXXIncludePaths(Base+Suffix, TargetArchDir + MultiLibSuffix,
|
|
|
|
DriverArgs, CC1Args))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
addSystemInclude(DriverArgs, CC1Args, Base + "/" + TargetArchDir + Suffix
|
|
|
|
+ MultiLibSuffix);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2011-11-06 04:17:13 +08:00
|
|
|
void Linux::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
|
|
|
|
ArgStringList &CC1Args) const {
|
|
|
|
if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
|
|
|
|
DriverArgs.hasArg(options::OPT_nostdincxx))
|
|
|
|
return;
|
|
|
|
|
2011-11-07 17:01:17 +08:00
|
|
|
// Check if libc++ has been enabled and provide its include paths if so.
|
|
|
|
if (GetCXXStdlibType(DriverArgs) == ToolChain::CST_Libcxx) {
|
|
|
|
// libc++ is always installed at a fixed path on Linux currently.
|
|
|
|
addSystemInclude(DriverArgs, CC1Args,
|
|
|
|
getDriver().SysRoot + "/usr/include/c++/v1");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-01-25 16:04:13 +08:00
|
|
|
// We need a detected GCC installation on Linux to provide libstdc++'s
|
|
|
|
// headers. We handled the libc++ case above.
|
|
|
|
if (!GCCInstallation.isValid())
|
|
|
|
return;
|
2011-11-06 18:31:01 +08:00
|
|
|
|
|
|
|
// By default, look for the C++ headers in an include directory adjacent to
|
|
|
|
// the lib directory of the GCC installation. Note that this is expect to be
|
|
|
|
// equivalent to '/usr/include/c++/X.Y' in almost all cases.
|
|
|
|
StringRef LibDir = GCCInstallation.getParentLibPath();
|
|
|
|
StringRef InstallDir = GCCInstallation.getInstallPath();
|
2012-06-19 09:26:10 +08:00
|
|
|
StringRef Version = GCCInstallation.getVersion().Text;
|
2012-09-03 17:05:50 +08:00
|
|
|
StringRef TripleStr = GCCInstallation.getTriple().str();
|
|
|
|
|
2013-03-07 01:14:05 +08:00
|
|
|
if (addLibStdCXXIncludePaths(LibDir.str() + "/../include",
|
|
|
|
"/c++/" + Version.str(),
|
|
|
|
TripleStr,
|
|
|
|
GCCInstallation.getMultiarchSuffix(),
|
|
|
|
DriverArgs, CC1Args))
|
|
|
|
return;
|
|
|
|
|
2012-09-03 17:05:50 +08:00
|
|
|
const std::string IncludePathCandidates[] = {
|
2011-11-06 18:31:01 +08:00
|
|
|
// Gentoo is weird and places its headers inside the GCC install, so if the
|
|
|
|
// first attempt to find the headers fails, try this pattern.
|
2012-09-03 17:05:50 +08:00
|
|
|
InstallDir.str() + "/include/g++-v4",
|
|
|
|
// Android standalone toolchain has C++ headers in yet another place.
|
|
|
|
LibDir.str() + "/../" + TripleStr.str() + "/include/c++/" + Version.str(),
|
2012-09-19 06:25:07 +08:00
|
|
|
// Freescale SDK C++ headers are directly in <sysroot>/usr/include/c++,
|
|
|
|
// without a subdirectory corresponding to the gcc version.
|
|
|
|
LibDir.str() + "/../include/c++",
|
2012-09-03 17:05:50 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
for (unsigned i = 0; i < llvm::array_lengthof(IncludePathCandidates); ++i) {
|
|
|
|
if (addLibStdCXXIncludePaths(IncludePathCandidates[i], (TripleStr +
|
|
|
|
GCCInstallation.getMultiarchSuffix()),
|
|
|
|
DriverArgs, CC1Args))
|
|
|
|
break;
|
2011-11-06 18:31:01 +08:00
|
|
|
}
|
2011-11-06 04:17:13 +08:00
|
|
|
}
|
|
|
|
|
2013-04-09 12:35:11 +08:00
|
|
|
bool Linux::isPIEDefault() const {
|
|
|
|
return IsPIEDefault;
|
|
|
|
}
|
|
|
|
|
2009-05-03 02:28:39 +08:00
|
|
|
/// DragonFly - DragonFly tool chain which can call as(1) and ld(1) directly.
|
|
|
|
|
2012-02-19 09:38:32 +08:00
|
|
|
DragonFly::DragonFly(const Driver &D, const llvm::Triple& Triple, const ArgList &Args)
|
|
|
|
: Generic_ELF(D, Triple, Args) {
|
2009-05-03 02:28:39 +08:00
|
|
|
|
|
|
|
// Path mangling to find libexec
|
2010-08-02 06:29:51 +08:00
|
|
|
getProgramPaths().push_back(getDriver().getInstalledDir());
|
2011-03-02 06:50:47 +08:00
|
|
|
if (getDriver().getInstalledDir() != getDriver().Dir)
|
2010-08-02 06:29:51 +08:00
|
|
|
getProgramPaths().push_back(getDriver().Dir);
|
2009-05-03 02:28:39 +08:00
|
|
|
|
2009-12-22 02:54:17 +08:00
|
|
|
getFilePaths().push_back(getDriver().Dir + "/../lib");
|
2009-05-03 02:28:39 +08:00
|
|
|
getFilePaths().push_back("/usr/lib");
|
2013-04-12 06:55:55 +08:00
|
|
|
if (llvm::sys::fs::exists("/usr/lib/gcc47"))
|
|
|
|
getFilePaths().push_back("/usr/lib/gcc47");
|
|
|
|
else
|
|
|
|
getFilePaths().push_back("/usr/lib/gcc44");
|
2009-05-03 02:28:39 +08:00
|
|
|
}
|
|
|
|
|
2013-03-20 11:05:54 +08:00
|
|
|
Tool *DragonFly::buildAssembler() const {
|
|
|
|
return new tools::dragonfly::Assemble(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tool *DragonFly::buildLinker() const {
|
|
|
|
return new tools::dragonfly::Link(*this);
|
2009-05-03 02:28:39 +08:00
|
|
|
}
|