Clang triple canonicalization


I am trying to build clang as a cross compiler and I am having some trouble getting it working. I configured clang with cmake options:

cmake …/llvm-3.3 -DCMAKE_BUILD_TYPE=Release -DLLVM_DEFAULT_TARGET_TRIPLE=i586-XXX-linux-gnu -DDEFAULT_SYSROOT=/usr/i586-XXX-linux-gnu/sys-root -DLLVM_TARGETS_TO_BUILD=X86

But clang -v reports:

Target: i386-XXX-linux-gnu

So clang is canonicalizing the i586 into i386. This is causing clang to fail to find all the gnu cross tools with names /usr/bin/i586-XXX-linux-gnu-*
Is there any good reason for this canonicalization? Does it make sense to disable it? What is the best way about solving this issue?



I figured out the normalization is done in llvm::sys::getDefaultTargetTriple. Changing the implementation to simply return LLVM_DEFAULT_TARGET_TRIPLE fixes the problem. I’m still not clear on why this normalization is done. Would it make sense to add a configure option to disable this normalization for cases where the target is known?

We do the same in FreeBSD, e.g. simply return LLVM_DEFAULT_TARGET_TRIPLE. Now, in theory ‘i586’ is incorrect, as ‘i386’ means the architecture, not the CPU, but in practice it is used all over the place anyway. :slight_smile:


I think this is more an emergent behaviour than design.

It is good to normalize (or canonicalize) the triples, to make sure we pass
the correct options down the sub-commands / sub-components of LLVM, but
only as long as the canonicalized triple reflects correctly the target
you're trying to.

I learnt the hard way that most of arm*-none-eabi were being converted to
armv4t--none-eabi because they were missing, and most only worked when you
set the cpu, fpu and abi manually on all stages, to guarantee that, even
with a bogus triple, the behaviour would be expected. That was several
years ago, much of that was fixed, but some odd cases still remain.

This is also not specific to Clang, but the LLVM's Triple is also lacking,
so both sides need serious review.

Regarding the specific names (i386 instead of i586), this is again,
historical. Some people think we should try to mimic GNU's triples as close
as possible, others think we should abandon triples altogether and start
with something else entirely. But the solution will probably be something
else in between... I'm hoping to be able to have a look at it in the near