-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Add std
support for armv7a-vex-v5
#145973
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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. |
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 |
This comment has been minimized.
This comment has been minimized.
@rustbot author |
Reminder, once the PR becomes ready for a review, use |
@rustbot ready |
Thanks for the updates here, I'll take a more thorough look through after the libs meeting (next Wednesday). |
☔ The latest upstream changes (presumably #146160) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
Some changes occurred in src/tools/cargo cc @ehuss |
This comment has been minimized.
This comment has been minimized.
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Think all of the review concerns are addressed. Going to run some hardware tests to make sure nothing regressed anyways (mainly around @rustbot ready |
Hardware tests seem fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updates look great! Noticed one last nit on error messages.
Please squash, r=me after that and the error message change
Done! Think things are in order (don't think I have permissions for |
Code changes look good to me! But on a history nit, for the squashed commit it looks like you aren't listed as the author. Since you prepared the final state, you probably want to Also you don't really need to keep all the squashed messages in the final commit message since they aren't relevant anymore. I know this is the default behavior for rebase |
Co-authored-by: Lewis McClelland <[email protected]>
Yeah, I squashed everything into the first commit, which is why it ended up that way. I've fixed that issue and added lewis back as a co-author. |
Looks great! Thanks for all the work here. @bors r+ |
Add `std` support for `armv7a-vex-v5` This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang#131530. This was a joint effort between me, ``@lewisfm,`` ``@max-niederman,`` ``@Gavin-Niederman`` and several other members of the [`vexide` project](https://github.com/vexide/). ## 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 of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support 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](rust-lang#131530 (comment)). ## SDK Linkage VEXos doesn't really ship with an official `libc` or 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 the `armv6k-nintendo-3ds` team's work in rust-lang#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options: - [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script. - [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps. - [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions. - Linking their own implementation or stubbing the functions required by libstd. The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main). ## 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](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially. Additionally, I have a working branch implementing the `panic_unwind` runtime 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.
Rollup of 14 pull requests Successful merges: - #145067 (RawVecInner: add missing `unsafe` to unsafe fns) - #145277 (Do not materialise X in [X; 0] when X is unsizing a const) - #145973 (Add `std` support for `armv7a-vex-v5`) - #146667 (Add an attribute to check the number of lanes in a SIMD vector after monomorphization) - #146735 (unstably constify float mul_add methods) - #146737 (f16_f128: enable some more tests in Miri) - #146766 (Add attributes for #[global_allocator] functions) - #146905 (llvm: update remarks support on LLVM 22) - #146982 (Remove erroneous normalization step in `tests/run-make/linker-warning`) - #147005 (Small string formatting cleanup) - #147007 (Explicitly note `&[SocketAddr]` impl of `ToSocketAddrs`) - #147008 (bootstrap.py: Respect build.jobs while building bootstrap tool) - #147013 (rustdoc: Fix documentation for `--doctest-build-arg`) - #147015 (Use `LLVMDisposeTargetMachine`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #145973 - vexide:vex-std, r=tgross35 Add `std` support for `armv7a-vex-v5` This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). 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 [`vexide` project](https://github.com/vexide/). ## 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 of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support 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](#131530 (comment)). ## SDK Linkage VEXos doesn't really ship with an official `libc` or 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 the `armv6k-nintendo-3ds` team's work in #95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options: - [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script. - [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps. - [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions. - Linking their own implementation or stubbing the functions required by libstd. The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main). ## 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](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially. Additionally, I have a working branch implementing the `panic_unwind` runtime 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.
This PR adds standard library support for the VEX V5 Brain (
armv7a-vex-v5
target). 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
vexide
project.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 thatlibstd
support 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
libc
or 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-3ds
team's work in #95897, we've opted not to directly linklibstd
to any SDK with the expectation that users will provide their own with one of the following options:vex-sdk-download
, which downloads an official proprietary SDK from VEX using a build script.vex-sdk-jumptable
, which is a compatible, open-source reimplementation of the SDK using firmware jumps.vex-sdk-pros
, which uses the PROS kernel as a provider for SDK functions.The
vex-sdk
crate used in the VEXos PAL provideslibc
-style FFI bindings for any compatible system library, so any of these options should work fine. A functional demo project usingvex-sdk-download
can be found here.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_unwind
runtime 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.