[+llvm-dev, cfe-dev]
Was "Re: [PATCH] ARM: allow inline atomics on Cortex M"
Attached is what I now think the patch ought to be.
Does unknownOS *always* mean bare-metal?
I'm not sure. It might be a good time to fork this thread, and start another
about triples for bare-metal...
Personally, I think we ought to add a 'None' entry to the OSType enum specifically for baremetal, and then map triples like arm-none-eabi and arm--eabi to it (but not arm-foobar-eabi, for example).
Thoughts?
Jon
[+llvmdev, -llvm-dev]
(Oopsies, llvmdev doesn't have a hyphen in it like all the others do)
Agreed.
-eric
[+llvmdev, -llvm-dev]
(Oopsies, llvmdev doesn't have a hyphen in it like all the others do)
>[+llvm-dev, cfe-dev]
>
>Was "Re: [PATCH] ARM: allow inline atomics on Cortex M"
>
>>
>>
>>>>Attached is what I now think the patch ought to be.
>>>
>>>Does unknownOS *always* mean bare-metal?
>>I'm not sure. It might be a good time to fork this thread, and start another
>>about triples for bare-metal...
>
>Personally, I think we ought to add a 'None' entry to the OSType enum
>specifically for baremetal, and then map triples like arm-none-eabi and
>arm--eabi to it (but not arm-foobar-eabi, for example).
What does 'bare-metal' mean in the context of a triple?
-Tom
[+llvm-dev, cfe-dev]
Was "Re: [PATCH] ARM: allow inline atomics on Cortex M"
Attached is what I now think the patch ought to be.
Does unknownOS *always* mean bare-metal?
I'm not sure. It might be a good time to fork this thread, and start another
about triples for bare-metal...Personally, I think we ought to add a 'None' entry to the OSType enum specifically for baremetal, and then map triples like arm-none-eabi and arm--eabi to it (but not arm-foobar-eabi, for example).
Thoughts?
Am I mistaken in that this is currently modeled as the following triple: {<arch>, <vendor>, Invalid, <environment>}. To help clarify what I mean, consider the following armv4 baremetal eabi target: armv7---eabi. It is arguably less than ideal for typing, but, it *should* work.
IIRC, config.sub uses unknown for the vendor field, and none for the os field, so the use of none may not be that bad.
[+llvm-dev, cfe-dev]
Was "Re: [PATCH] ARM: allow inline atomics on Cortex M"
Attached is what I now think the patch ought to be.
Does unknownOS *always* mean bare-metal?
I'm not sure. It might be a good time to fork this thread, and start another
about triples for bare-metal...Personally, I think we ought to add a 'None' entry to the OSType enum specifically for baremetal, and then map triples like arm-none-eabi and arm--eabi to it (but not arm-foobar-eabi, for example).
Thoughts?
Am I mistaken in that this is currently modeled as the following triple: {<arch>, <vendor>, Invalid, <environment>}. To help clarify what I mean, consider the following armv4 baremetal eabi target: armv7---eabi. It is arguably less than ideal for typing, but, it *should* work.
IIRC, config.sub uses unknown for the vendor field, and none for the os field, so the use of none may not be that bad.
<arch>-<vendor>-none-<environment>
has the merit of making the "none" explict (although it's agreed that absence of a statement could be taken as defaulting to none)
Being explicit perhaps simplifies decoding default cases for the driver (e.g. if the User types 'arm-elf').
[+llvm-dev, cfe-dev]
Was "Re: [PATCH] ARM: allow inline atomics on Cortex M"
Attached is what I now think the patch ought to be.
Does unknownOS *always* mean bare-metal?
I'm not sure. It might be a good time to fork this thread, and start another
about triples for bare-metal...Personally, I think we ought to add a 'None' entry to the OSType enum specifically for baremetal, and then map triples like arm-none-eabi and arm--eabi to it (but not arm-foobar-eabi, for example).
Thoughts?
Am I mistaken in that this is currently modeled as the following triple: {<arch>, <vendor>, Invalid, <environment>}. To help clarify what I mean, consider the following armv4 baremetal eabi target: armv7---eabi. It is arguably less than ideal for typing, but, it *should* work.
IIRC, config.sub uses unknown for the vendor field, and none for the os field, so the use of none may not be that bad.
<arch>-<vendor>-none-<environment>
has the merit of making the "none" explict (although it's agreed that absence of a statement could be taken as defaulting to none)
Being explicit perhaps simplifies decoding default cases for the driver (e.g. if the User types 'arm-elf').
arm-elf should just funnel to arm-none-elf via canonicalization. 
-eric
My confusion here is that bare-metal == NO OS, rather than Unknown OS.
The former is an explicit statement, saying you don't (generally) have
shared libraries, systemcalls, etc. The latter can (but not
necessarily does) depend on the platform, since the "default"
behaviour could be to assume OS=Linux or whatever.
I don't think there's a use case today where that fails, but I never
liked the extensive use people make of the "default" behaviour. On
ARM, we tend to add "none" as in arm-none-eabi to enforce bare-metal
and strict EABI compatibility.
cheers,
--renato
Eric,
Attached are patches for llvm and clang that implement this.
I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be.
SPIR triples were one place where I was uncertain... I'm not sure if they'd prefer to use 'none' or rather just omit that part of the triple. So on those, I've left them to use Triple::UnknownOS.
Cheers,
Jon
baremetal.clang.diff (1.72 KB)
baremetal.llvm.diff (3.62 KB)
[+llvm-commits, +cfe-commits] (forgot to add them too)
baremetal.clang.diff (1.72 KB)
baremetal.llvm.diff (3.62 KB)
Attached Message Part (140 Bytes)
Hi Jonathan,
The main issue with your patch is that it can change user expected
behaviour, and I can't tell you what is the expected behaviour in
Darwin or BSD. If people usually use "unknown" in triples, this will
break their builds. If not, this could break the build of someone who
does.
My advice is to create a "default" mechanism for the affected targets,
something that maps "unknwon" to "whatever" (usually "none" but could
be "linux" or "win" depending on the rest of the triple). To do that,
you'll have to learn what is the expected default on each.
You could just completely ignore the expectation and just commit your
patch as it is, but only with agreement from the rest of the community
(Darwin, x86-Linux and FreeBSD). On ARM+Linux, "unknown" is basically
the same as "none", aka "bare-metal". But I can't tell you on anything
else. So, while I don't mind the change, people might do.
cheers,
--renato
I think (Hat: FreeBSD) we only expect to see unknown in the vendor field (e.g. i386-unknown-freebsd). If the OS field is unknown, rather than freebsd, then it's not one of ours and we aren't likely to care. I don't really like the way that we conflate OS with ABI, but then I don't really like anything about triples...
David
Except that last rant, I agree with s/FreeBSD/NetBSD.
Joerg
The main issue with your patch is that it can change user expected
behaviour, and I can't tell you what is the expected behaviour in
Darwin or BSD. If people usually use "unknown" in triples, this will
break their builds. If not, this could break the build of someone who
does.
Renato,
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.
Do you know who the right folks are to ask about the SPIR triples?
Tim,
This patch changes behavior a little for macho_embedded targets (i.e. from OSType::Unknown to OSType::NoneOS). I see that there is existing code to transform triples from things like thumbv7-apple-darwin into thumbv7m-apple-unknown-macho. Do you have an expectation to support users who are using the latter form of triples who would be surprised by the change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho (i.e. their thumbv7m-apple-unknown-macho builds no longer work)? Is this a case where all three triples are to mean the same thing?
I think (Hat: FreeBSD) we only expect to see unknown in the vendor field (e.g. i386-unknown-freebsd). If the OS field is unknown, rather than freebsd, then it's not one of ours and we aren't likely to care. I don't really like the way that we conflate OS with ABI, but then I don't really like anything about triples...
David, thanks!
Cheers,
Jon
Hi Jon,
This patch changes behavior a little for macho_embedded targets (i.e. from
OSType::Unknown to OSType::NoneOS). I see that there is existing code to
transform triples from things like thumbv7-apple-darwin into
thumbv7m-apple-unknown-macho. Do you have an expectation to support users
who are using the latter form of triples who would be surprised by the
change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho (i.e.
their thumbv7m-apple-unknown-macho builds no longer work)?
Mostly people should be getting these triples (from out perspective)
via "-arch armv7m" and similar, so things should just work for them.
Is this a case where all three triples are to mean the same thing?
Well, "-darwin" is different, but that's already taken care of in the
driver. I'm actually still a little hazy on when the two being
disambiguated would ever be treated differently. But no doubt someone
has plans, so I'll watch with interest.
Cheers.
Tim.
Hi Jon,
This looks reasonable to me.
Cheers,
Amara
Hi Jonathan,
This looks a bit odd. Any reason for the unknown->none conflating in
this way? For most (all) of the ports unknown-elf works the same as
none-elf. I'm also not sure if someone decided to have,
arm-codesourcery-elf that this would still work with the patch.
Thoughts?
-eric
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
Hi Jonathan,
This looks a bit odd. Any reason for the unknown->none conflating in
this way?
I'm trying to un-conflate them... What specifically seems odd to you about it?
IMHO, when a user doesn't explicitly specify that a target's OS is 'none' (perhaps they left it off, or they explicitly said 'unknown') then they probably don't intend to target bare-metal.
For most (all) of the ports unknown-elf works the same as
none-elf.
Yes, and so would santas-elf 
All three of these examples fall into the same "it doesn't match anything else OSType::UnknownOS bucket", and I want to change that.
I'm also not sure if someone decided to have,
arm-codesourcery-elf that this would still work with the patch.
Well, depends on what you mean by 'work', and also what is meant by that triple. To me, it means:
ArchType: arm
VendorType: CodeSourcery
OSType: UnknownOS (not bare-metal)
EnvironmentType: UnknownEnvironment
ObjectFormatType: elf
If a user wants the baremetal version of that hypothetical triple, my argument is that they should say arm-codesourcery-none-elf, and they would get:
ArchType: arm
VendorType: CodeSourcery
OSType: NoneOS
EnvironmentType: UnknownEnvironment
ObjectFormatType: elf
Does that make sense?
Cheers,
Jon
This was broken before... "we" didn't do anything...
I don't know the whole story but it was supposed to be a triple and
people started using the third field to mean different things, then
they added an interchangeable fourth field, and then it's impossible
to distinguish.
I cry every time I have to think about it.
--renato