Update a comment to clarify that searching the target triple bin

directory for programs used by the driver is actually the standard
behavior we want to be compatible with GCC cross compilers -- it isn't
specific to SUSE or any other distro.

Also start fleshing out testing of the different cross compilation
patterns, both with a new very bare-bones tree of cross compilers and by
extending the multilib trees. Currently, we don't correctly model doing
a cross compile using the non-triple target of a bi-arch GCC install,
but I'll add support for that (and tests) next.

llvm-svn: 184499

1 files changed, 8 insertions, 2 deletions

diff --git a/clang/lib/Driver/ToolChains.cpp b/clang/lib/Driver/ToolChains.cpp
index 5c0ab55a048..1c208eea44e 100644
--- a/clang/lib/Driver/ToolChains.cpp
+++ b/clang/lib/Driver/ToolChains.cpp
@@ -2219,8 +2219,14 @@ Linux::Linux(const Driver &D, const llvm::Triple &Triple, const ArgList &Args)
   llvm::Triple::ArchType Arch = Triple.getArch();
   std::string SysRoot = computeSysRoot(Args);
 
-  // OpenSuse stores the linker with the compiler, add that to the search
-  // path.
+  // Cross-compiling binutils and GCC installations (vanilla and OpenSuse at
+  // least) put various tools in a triple-prefixed directory off of the parent
+  // of the GCC installation. We use the GCC triple here to ensure that we end
+  // up with tools that support the same amount of cross compiling as the
+  // detected GCC installation. For example, if we find a GCC installation
+  // targeting x86_64, but it is a bi-arch GCC installation, it can also be
+  // used to target i386.
+  // FIXME: This seems unlikely to be Linux-specific.
   ToolChain::path_list &PPaths = getProgramPaths();
   PPaths.push_back(Twine(GCCInstallation.getParentLibPath() + "/../" +
                          GCCInstallation.getTriple().str() + "/bin").str());