Status of the riscv32im-risc0-zkvm-elf target

[Noratrieb]

We currently have a target called riscv32im-risc0-zkvm-elf, which targets the RISC Zero Zero Knowledge VM. This target is maintained by @SchmErik, @jbruestle, @flaub #134721 has revealed some issues in this target.

The biggest issue is that the target sets target_os = "zkvm". A "Zero Knowledge VM" is a generic concept and not an operating system. The correct target_os would be risc0.

But there is another question, whether this target should exist in the first place. The alternative to this target would be using the existing riscv32im-unknown-none-elf target with a RISC0-provided crate for the system calls.

The thing that is currently gained from having this target is that it can have std, where the very few syscalls that exist are used to implement some standard library interfaces.
Concretely, the following functionality is provided:

• program arguments
• environment variables (read-only)
• stdio
• the system global allocator
• and of course HashMap
• (no_threads) std::sync

other features like std::fs, std::io, std::process, std::thread, std::time, std::net are not supported.

@SchmErik, who is a maintainer of the target, highlights how the std support is useful in #134721 (comment):

Having std support is important to us because it allows developers to use crates outside of no_std. This has enabled many others to use our target much more easily with existing crates

Additionally, they mentioned how having the target allows them to add cfgs to forked ecosystem crates to make them use more of RISC Zero's APIs (though this could also be implemented without a target and a normal custom cfg).

It is always unsatisfactory to have targets with such incomplete standard libraries (at least it's not as bad as wasm32-unknown-unknown in this case). On the other hand, (just like the wasm target) the APIs that are implemented are likely useful.

This issue is about figuring out what to do with this target, whether to keep it (renamed) or remove it alltogether.

[workingjubilee]

As far as target APIs we would consider as a minimum basis, notably, in the recent discussion on a prospective VexOS target, having at least a rudimentary form of std::time was considered important.

@SchmErik In general, people use Rust because "if it compiles, it works". However, we have already encountered this problem with wasm32-unknown-unknown: by having an almost-entirely-stubbed-out stdlib implementation, we create a situation where if it compiles, it DOESN'T work.

And it seems to me many people will discover their code doesn't work at significant expense! That is, because this is a target designed primarily for computation on expensive-to-operate distributed systems, even the cheapest executions can be significantly more costly than simply running the compiler and executing a built program on my local machine. Time, if nothing else.

The model for the wasm32-unknown-unknown target is a quagmire that is due to a unique situation for wasm32 and does not seem to apply in your case. It exists because there was an unwillingness to commit to e.g. having both a wasm32-wasi and a wasm32-web target... and also, wasm32-wasi didn't even exist yet. A lot was in-flux and still being designed at the time.

Regarding the target_os matter: I think you have somewhat misunderstood how to use the compiler's configuration features if you think a target_os or even target_vendor is required, honestly.

[Urgau]

We (T-compiler) should probably always involve T-libs when a target can only have "incomplete standard libraries" before accepting/merging a new target (with/without std).

As @workingjubilee already mentioned, T-libs was in the loop regarding the recent VexOS target, and even-through that target is only missing std::process, std::thread and std::net it was deemed insufficient for Tier >= 2 (the target was allowed for Tier 3).

We discussed this in the libs meeting today. While this is indeed missing a lot of what would normally be present in a std target, it does at least have the basics down like support for Instant (which is one of the biggest issues with wasm32-unknown-unknown). We're happy for this to be accepted at tier 3 but would likely reject it for higher tiers.

Based on that I would be in favour of removing std support and fixing target_os, which if I understand correctly would be equivalent to riscv32im-unknown-none-elf, therefore rendering the target irrelevant (and so should just be removed?).

[Noratrieb]

Removing std would imply removing the target alltogether, as std is the only point of the target.

[Noratrieb]

I'm also nominating for libs discussion about whether libs wants to have a target with std like this.

[Amanieu]

From the target tier policy document:

Tier 3:

std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement.

Tier 2:

Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.

The libs team is happy to have as a tier 3 target but would block it from any higher tier.

[apiraino]

Discussed in T-compiler triage.

So, we're fine with a stubbed std implementation. The question is rather about the target_os, changing that would break the target (comment).

One solution could be to giving them large time (say, 6 months) to fix the target_os and then swtich the compile target (comment).

@rustbot label -I-compiler-nominated