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 [[email protected]](mailto:[email protected]). 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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
