[cfe-dev] [LLVMdev] [PATCH] triples for baremetal

[Renato Golin]

On 24 June 2014 14:58, Jonathan Roelofs <jonathan at codesourcery.com> wrote:
> I would like to go this route, providing I can get support from the
> community that this is the direction we'd all like to take... I'd rather not
> make triples more complicated by introducing lots of special cases.

Hi Jonathan,

I love breaking legacy stuff, but this is not just up to me. There are
a lot of odd triples (quadruples, quintuples and the like) out there
that will defy any logic, and they "seem" to work on LLVM as well as
GCC (maybe not in the same way) because people can't distinguish or
detect the problems well enough.

Having said that, Eric raised the same concern I did, which is that
unknown != none. Empty string (ex. arm-eabi) defaults to "unknown",
and only "none" is NoneOS. That, I think, is paramount because it
gives a robust mechanism to reason about triples.

Completely orthogonal is what to do when you're facing an empty string
or "unknown". My view is that there should be a mechanism, per {
target / OS / env }, that would decide, based on the other values,
what to do with that. Of course, this mechanism has to be lazily
evaluated, so that you have information about the environment while
deciding what to do with the OS.

Completely bogus examples would be:

arm-eabi -> arm-none-eabi
arm-gnueabi -> arm-linux-gnueabi
arm-elf -> arm-freebsd-elf
arm-apple -> arm-apple-darwin

and the mapping of what goes where will depend on FreeBSD, Darwin,
Linux, etc. for OS, and ARM, x86, PPC, MIPS for the
architecture/vendor, etc.


> Do you know who the right folks are to ask about the SPIR triples?

Tim, David and Eric are already sharing their opinions, which is great.

>From an EABI point of view, unknown == none == <empty>. I'm not so
sure about the gnueabi/hf, which I'd assume would default to Linux,
but would be glad to learn I'm wrong.

But, perhaps more importantly, we need to be at least reasonably close
to GCC's behaviour. This is a particularly troubling issue on build
systems, when the triple is already broken enough to make anyone cramp
for weeks, and behaving erratically will only make it less likely that
people will try Clang/LLVM in place of GCC in the future.

Thread lightly, double check with GCC and make sure triple parsing is
orthogonal to triple default behaviour. We already have problems in
the parser because the triple changes under the parser's feet.

cheers,
--renato