[clang] [llvm] [Triple] Make an target triple "os" for firmware (PR #176272)

[Ian Anderson via cfe-commits]

ian-twilightcoder wrote:

> > > > Oh wait, this is limited to the Darwin platform? In that case, can we have some negative tests to ensure that something like `aarch64-unknown-linux-firmware` or `aarch64-unknown-firmware` is not processed as a valid triple?
> > > 
> > > 
> > > Firmware definitely sounds like it would be generally applicable to other platforms, could you include Apple/Darwin in the name of functions to make it clear that this is just for Apple platforms? As far as I can tell most other embedded operating systems just use `unknown/none-elf ` for ELF platforms and that works fine.
> > 
> > 
> > Does it have to just be for Apple platforms? It seems like it might be generally useful for anyone to add their own semantics on top. There's no reason people can't just keep using `x86_64-unknown-none-elf` for firmware, but if someone else had a firmware ecosystem they could use e.g. `x86_64-nvidia-firmware` if they wanted?
> 
> I think that we do need to limit it unless you are getting this run past the GNU project at [config-patches at gnu.org](mailto:config-patches at gnu.org). This is a change to how config.sub, config, and autotools normalise and process triples. If this is limited to Apple, then while they may still have an opinion, I think it is okay to treat this as a vendor extension and add it to LLVM.

If I can avoid doing anything with gcc that's ideal, Apple employees are really allowed to even speak the phrase "gcc" 😉 

> I don't have a conceptual issue with the idea of introducing a firmware environment, but this should be either very specifically an Apple only thing or should be run past the GNU tools maintainers as well.
> 
> > It is a little unusual in that it's not a specific os and kind of needs a specific vendor for it to have any meaning. Even apple-firmware isn't a specific os, It's more of a collection of os-like related platforms that we need some kind of common way to refer to in the compiler.
> 
> Interesting. I think that this should be codified into the triple parsing and we should have tests to reject the invalid triples. Basically, it sounds like: `aarch64-unknown-none-firmware-coff` would not be a valid triple? (ARM64, no vendor extensions, no OS, PE/COFF object file for a firmware environment.

We wanted to use `firmware` as OS to represent the overall platform, and then use the environment to codify specific flavors. I think it should be easy enough to make the triple parser ignore a "firmware" os if the vendor isn't "apple" (or isn't "unknown"?).

https://github.com/llvm/llvm-project/pull/176272