search

bytecodealliance / target-lexicon

Target "triple" support
Apache License 2.0
47 stars 42 forks source link

add OperatingSystem::Sel4 and Environment::Robigalia #65

Closed emberian closed 1 year ago

emberian commented 3 years ago

https://robigalia.org/ has been maintaining custom target JSON for some time with the ARCH-sel4-robigalia targets. at some point something somewhere started depending on target-lexicon and now i can't build without informing this crate about the existence of my target! i designed RFC 131 so that i wouldn't have to edit the compiler to add targets, so i found this disappointing :(

the fel4 project uses the ARCH-sel4-fel4 pattern but has been entirely dormant for several years and i don't know that anyone will notice that it's missing here

sunfishcode commented 3 years ago

Would it be possible to identify which component is depending on target-lexicon, and how it's being used?

target-lexicon is mainly used by tools the way that rustc uses the "llvm-target" field of its target description. LLVM, for its part, doesn't recognize custom OS names either, but as I understand it, one typically just picks an "llvm-target" for a target that LLVM does support. (If you do need a new ABI, you have to teach LLVM about it anyway, and in that case adding the target string is a minor task in comparison.)

bjorn3 commented 3 years ago

Target-lexicon directly includes the rust target that cargo tells it about in the TARGET env var for the HOST constant. It doesn't read the llvm-target field from the target specification. This means that target-lexicon must know about the rust target and not the llvm target.

emberian commented 3 years ago

@sunfishcode wasmtime (which i started depending on directly in one of my examples) and rustc_codegen_cranelift (i'm planning on targeting a rustc for this platform too)

emberian commented 3 years ago

i could tweak the build script to read the target spec via rustc -Z unstable-options=y --print target-spec-json --target $TARGET and use the llvm-target, do you think that would be fine?

bjorn3 commented 3 years ago

Target-lexicon must work in stable, as both Cranelift and Wasmtime must.

rustc_codegen_cranelift (i'm planning on targeting a rustc for this platform too)

If you have any problems, feel free to open an issue at https://github.com/bjorn3/rustc_codegen_cranelift or DM me on either the bytecodealliance or rust-lang zulip. Do know that if you do a full bootstrap using cg_clif, the resulting rustc is way too slow to be useful as cg_clif barely does any optimizations. You will likely want to use the rustc that was directly built using the bootstrap compiler. (this may be the default anyway, I can't remember)

sunfishcode commented 3 years ago

As a quick comment on the PR itself, the one thing missing here is a line to roundtrip_known_triples in src/targets.rs using the new values being defined here in a full triple to ensure that it round-trips to a string and back. I just created https://github.com/bytecodealliance/target-lexicon/pull/66 to fix the CI failures, other than that this just needs a rustfmt.

In general, I'm in favor of not requiring people to submit PRs to repos like this just to use custom targets, and am open to suggestions as to how best to proceed here.

In theory, llvm_target allows a disconnect between the custom target's own name and the ABI used by LLVM. And for common use cases for target-lexicon, it seems like a similar disconnect ought to be possible. A custom target is either going to reuse an existing ABI, in which case compiler-like tools don't really need to know about the custom target, or have a new new ABI, in which case you likely need to teach the tools about the new ABI anyway. That suggests that one way forward might be to not add the new targets here, but to simply find a way to set HOST in some other way.

sunfishcode commented 1 year ago

target-lexicon now has support or custom vendors, where it just holds a String. I believe this is the best path forward for people maintaining custom targets.