Avoid static list of LLVM triples #1431

madsmtm · 2025-03-13T11:38:18Z

Continue the work in #1413, and avoid the pre-generated list of Clang/LLVM triples in favour of constructing it from the target information.

I'd like to make sure that this list matches what rustc, so I'm filing PRs to make their use of LLVM triples simpler:

Fix armv7-sony-vita-newlibeabihf LLVM target triple rust#138426
Fix RISC-V VxWorks LLVM target triples rust#138427
Fix x86_64-unknown-illumos LLVM target triple rust#138429
Fix uclibc LLVM target triples rust#138431
A PR for avoiding arch-only LLVM triples (riscv32) in favour of more components (riscv32-unknown-none)
WIP more?

Alternatively, maybe use rustc --print llvm-tuple if that becomes viable.

The text was updated successfully, but these errors were encountered:

…youxu Fix RISC-V VxWorks LLVM target triples The targets `riscv32-wrs-vxworks` and `riscv64-wrs-vxworks` uses the plain `$ARCH` LLVM triple, which LLVM normalizes to `$ARCH-unknown-unknown`, we should use `$ARCH-unknown-linux-gnu$ABI` which is consistent with the the other VxWorks targets. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. Alternative: Pass `$ARCH-unknown-none` in the other VxWorks LLVM triples, I don't know anything about VxWorks, so am unsure which is the most correct option. CC target maintainer `@biabbas.` r? jieyouxu

Rollup merge of rust-lang#138427 - madsmtm:vxworks-llvm-target, r=jieyouxu Fix RISC-V VxWorks LLVM target triples The targets `riscv32-wrs-vxworks` and `riscv64-wrs-vxworks` uses the plain `$ARCH` LLVM triple, which LLVM normalizes to `$ARCH-unknown-unknown`, we should use `$ARCH-unknown-linux-gnu$ABI` which is consistent with the the other VxWorks targets. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. Alternative: Pass `$ARCH-unknown-none` in the other VxWorks LLVM triples, I don't know anything about VxWorks, so am unsure which is the most correct option. CC target maintainer `@biabbas.` r? jieyouxu

Fix RISC-V VxWorks LLVM target triples The targets `riscv32-wrs-vxworks` and `riscv64-wrs-vxworks` uses the plain `$ARCH` LLVM triple, which LLVM normalizes to `$ARCH-unknown-unknown`, we should use `$ARCH-unknown-linux-gnu$ABI` which is consistent with the the other VxWorks targets. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. Alternative: Pass `$ARCH-unknown-none` in the other VxWorks LLVM triples, I don't know anything about VxWorks, so am unsure which is the most correct option. CC target maintainer `@biabbas.` r? jieyouxu

…ouxu Fix `uclibc` LLVM target triples `uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag). In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. **There are no target maintainers for these targets.** So I'll CC `@lancethepants` and `@skrap` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights. r? jieyouxu

…ouxu Fix `uclibc` LLVM target triples `uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag). In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. **There are no target maintainers for these targets.** So I'll CC ``@lancethepants`` and ``@skrap`` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights. r? jieyouxu

Rollup merge of rust-lang#138431 - madsmtm:uclibc-llvm-target, r=jieyouxu Fix `uclibc` LLVM target triples `uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag). In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. **There are no target maintainers for these targets.** So I'll CC ``@lancethepants`` and ``@skrap`` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights. r? jieyouxu

Fix `uclibc` LLVM target triples `uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag). In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. **There are no target maintainers for these targets.** So I'll CC ``@lancethepants`` and ``@skrap`` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights. r? jieyouxu

Fix `armv7-sony-vita-newlibeabihf` LLVM target triple It was previously normalized by LLVM to `thumbv7a-vita-unknown-eabihf` (can be seen with `clang -target thumbv7a-vita-eabihf -v`), which seems wrong, as Vita is the OS name. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. CC target maintainers `@nikarh,` `@pheki` and `@ZetaNumbers.` r? jieyouxu

Fix `armv7-sony-vita-newlibeabihf` LLVM target triple It was previously normalized by LLVM to `thumbv7a-vita-unknown-eabihf` (can be seen with `clang -target thumbv7a-vita-eabihf -v`), which seems wrong, as Vita is the OS name. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. CC target maintainers ``@nikarh,`` ``@pheki`` and ``@ZetaNumbers.`` r? jieyouxu

Rollup merge of rust-lang#138426 - madsmtm:vita-llvm-target, r=jieyouxu Fix `armv7-sony-vita-newlibeabihf` LLVM target triple It was previously normalized by LLVM to `thumbv7a-vita-unknown-eabihf` (can be seen with `clang -target thumbv7a-vita-eabihf -v`), which seems wrong, as Vita is the OS name. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. CC target maintainers ``@nikarh,`` ``@pheki`` and ``@ZetaNumbers.`` r? jieyouxu

madsmtm added the bug label Mar 13, 2025

madsmtm self-assigned this Mar 13, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Avoid static list of LLVM triples #1431

Avoid static list of LLVM triples #1431

madsmtm commented Mar 13, 2025

Avoid static list of LLVM triples #1431

Avoid static list of LLVM triples #1431

Comments

madsmtm commented Mar 13, 2025