[llvm-commits] PATCH: Add support for tracking and exposing the host triple

[James Molloy]

Hi Chandler,

 

The patch looks good to me, although I’m wondering why Clang needs to care what it was *built* to run on, as opposed to what it is actually running on at runtime.

 

For example, I compile on RHE3 for RHE3, then run on RHE5. Clang should surely understand that it is hosted on RHE5 and act accordingly. So why is this information needed as a build time constant?

 

Cheers,

 

James

 

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: 24 January 2012 11:59
To: <llvm-commits at cs.uiuc.edu>; Eric Christopher
Subject: [llvm-commits] PATCH: Add support for tracking and exposing the host triple

 

Attached is a patch to add support for tracking and exposing the host triple. This is one of the many steps along the way to cleaning up the Clang driver. In many places within Clang, we need to reason about the *host*, not the target, in order to decide how to behave. For example, this is at issue when deciding where within the host machine we should look for the target's toolchain. While in some cases, there is a canonical location that the target *always* uses, in other cases both can be relevant. Consider the Debian multiarch case where we will often want to use '/usr/lib/<host-triple>/gcc/<target-triple>/<version>/crtbegin.o'. In other cases, we may need to check whether the host triple might contain a toolchain capable of targeting our target. This happens frequently when working in a bi-arch world, where the GCC installed under 'i386-pc-linux-gnu' is actually capable of targeting 'x86_64-pc-linux-gnu' thanks to the '-m64' flag.

 

Some time back an effort was undertaken which simply blanket renamed 'Host' to 'Target' in many places. This didn't really address the fundamental problem, and in my mind made things a bit more confusing. Thus in most places in the driver, we treat the DefaultTargetTriple as the *host* triple, compute the HostInfo from it, and then *modify* it to produce the target triple. Ow. Other times, we modify it first, and assume that the post-modification triple is still a viable host triple.

 

All of this gets simple if we simply have access to both triples the entire time. We can make rational decisions about when we should and should not use the host information or the target information. Also, it will become immediately clear from the code which is in fact in use.

 

Again, this is just the first step, but it touches autoconf and a bunch of other stuff so I wanted someone else to glance at it before I checked it in. I'll also need someone to regenerate the config.h and the configure scripts as I don't have easy access to the proper versions. If someone can send me those patched files i can submit as one patch to keep the build bots happy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120124/56a6348a/attachment.html>