New cargo target detection regress *-esp-idf target builds. #1262
Comments
|
Hello, what cargo/rustc version are you using? cc try to use cargo env var passed to the build-script first before falling back to using pre-generated targets. I checked our pre-generated targets and they are fine, so I think it's due to the rustc/cargo version you use. |
|
This is on current rustc nightly The same setup is working with setting The two notable env vars here are |
|
That's strange I can't find anything in target/generated.rs Can you show me where the riscv32imc_zicsr_zifencei-esp-espidf is used? Is it in the args passed to the compiler? Also cc @madsmtm |
|
In the past it was the case that rust / llvm where following the ISA spec 2.0, In there words the We then needed to somehow not break the ecosystem and bridge the gap between the rust/llvm world and gcc toolchain version that were introduced into newer esp-idf targets. This lead us to manually injecting a "new target" into cc-rs via cmake config in code like this: 455 let mut cmake_config = cmake::Config::new(&out_dir);
473 if target == "riscv32imc-esp-espidf" {
474 cmake_config.target("riscv32imc_zicsr_zifencei-esp-espidf");
475 } else if target == "riscv32imac-esp-espidf" {
476 cmake_config.target("riscv32imac_zicsr_zifencei-esp-espidf");
477 } else if target == "riscv32imafc-esp-espidf" {
478 cmake_config.target("riscv32imafc_zicsr_zifencei-esp-espidf");This would end up creating the right invocation for the newer gcc version's. I think this is what is now broken. Have to look closer tomorrow at this. |
|
Thanks, so gcc start using newer schema and we need some mapping here? |
|
I'm not against adding custom code for handling these targets, preferably in the |
|
In a perfect world cc-rs would have info about the gcc version in the Tool struct or something. Either knowing its gcc12+ or a older version. And then if it sees riscv32imc it would emit -march=rv32imc for the older compiler versions and --march=rv32imc_zicsr_zifencei, but i guess we don't have this luxury. At least in the default case. That is one of the points why we currently still always emitting the Still have to test into how cmake crate handels the stuff when we would change it directly. |
I think that might be doable? Our |
IMO it is not "just" about the ESP IDF targets ( I think currently, every single RISCV target is affected, so this future custom code that emits this extra It is a RISCV ISA 2.0 vs 2.1 confusion, in that Rust+LLVM still follow ISA 2.0 (right?), while GCC >= 12 follows ISA 2.1. |
|
Related: rust-lang/cmake-rs#225 |
Since it might not be clear how this ^^^ is related:
The reason why we can't just switch off the flags' generation logic of But I think regardless, the "zicsr" and "zifencei" problem needs to be solved anyway, if not for us, then for those folks that might want Perhaps the reason is the combination of the facts that at least RISCV32 is still new-ish, and then these targets - when used from Rust - tend to be used baremetal-only (i.e. no C code around to compile with GCC as these are usually MCU targets). With the notable exception of the |
Vollbrecht
changed the title
Regression introduced in:
cc-rs 1.1.32.Problem: The target is misidentified as
riscv32imc_zicsr_zifencei-esp-espidf. While this would be a "correctly" formed target for a riscv target with respect to riscv ISA version 2.1, this is not a correct target description for any esp-idf target introduced on ISA 2.0.The esp-idf targets where added while the underlying compiler still supported the riscv ISA 2.0 that did not include any
zicsr_zifenceidescription. E.g the official names are listed https://doc.rust-lang.org/rustc/platform-support/esp-idf.html#requirements there.The text was updated successfully, but these errors were encountered: