Add std support for armv7a-vex-v5
#145973
Conversation
rustbot
added
A-tidy
|
Some changes occurred in src/doc/rustc/src/platform-support cc @Noratrieb These commits modify the If this was unintentional then you should revert the changes before this PR is merged. These commits modify compiler targets. The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging. |
|
|
||
| pub fn exists(path: &Path) -> io::Result<bool> { | ||
| let path = CString::new(path.as_os_str().as_encoded_bytes()) | ||
| .map_err(|_| io::Error::new(io::ErrorKind::InvalidData, "Path contained a null byte"))?; |
There was a problem hiding this comment.
Is this failure case actually possible, considering that this platform's OsString probably shouldn't allow null bytes?
There was a problem hiding this comment.
I think that this check is probably a good thing to have, but we shouldn't be doing it ourselves. I'll switch to small_c_string::run_path_with_cstr which is what the unix PAL (and basically all other targets except solid) use.
|
I think the limitations here seem fine, and from a quick skim nothing jumps out to me as problematic. Nominating to make sure the team doesn't have any concerns. @rustbot label +I-libs-nominated |
rustbot
added
the
I-libs-nominated
This comment has been minimized.
This comment has been minimized.
| @@ -84,6 +84,11 @@ wasi = { version = "0.11.0", features = [ | |||
| r-efi = { version = "5.2.0", features = ['rustc-dep-of-std'] } | |||
| r-efi-alloc = { version = "2.0.0", features = ['rustc-dep-of-std'] } | |||
|
|
|||
| [target.'cfg(target_os = "vexos")'.dependencies] | |||
| vex-sdk = { version = "0.27.0", features = [ | |||
There was a problem hiding this comment.
As a note, this version has a docs failure https://docs.rs/crate/vex-sdk/0.27.0
There was a problem hiding this comment.
Yeah, I noticed that. docs.rs has given me hell in the past when it comes to crates built for unconventional targets. I think it's likely we published 0.27.0 before they updated their server to a nightly version supporting armv7a-vex-v5. If that's a blocker for getting this PR in then I can push a new version and just lie in the docs.rs config by telling it to build for armv7a-none-eabi. The previously documented version should have a more or less identical API surface.
There was a problem hiding this comment.
No it's not a blocker here, this was just a heads up that you might want to poke it
This PR adds standard library support for the VEX V5 Brain (
armv7a-vex-v5target). It is more-or-less an updated version of the library-side work done in #131530.This was a joint effort between me, @lewisfm, @max-niederman, @Gavin-Niederman and several other members of the
vexideproject.Background
VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as
std::net,std::process, and most ofstd::thread). A more comprehensive list of what does or doesn't work is outlined in the updated target documentation. Despite these limitations, we believe thatlibstdsupport on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see this comment.SDK Linkage
VEXos doesn't really ship with an official
libcor POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of thearmv6k-nintendo-3dsteam's work in #95897, we've opted not to directly linklibstdto any SDK with the expectation that users will provide their own - either throughvex-sdk-build(which will download the official SDK from VEX),vex-sdk-jumptable(a compatible, open-source reimplementation), or potentially through linking the PROS kernel. Thevex-sdkcrate used in the VEXos PAL provideslibc-style FFI bindings for any compatible system library, so any of these options should work fine.Future Work
This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently gross enough to drive us away from supporting this officially.
Additionally, I have a working branch implementing the
panic_unwindruntime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.