-
Notifications
You must be signed in to change notification settings - Fork 12.1k
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
use posix_memalign on almost all Unix targets #125271
Conversation
rustbot has assigned @workingjubilee. Use |
"Horizon" is the name of the Nintendo Switch's system software. The Vita is just the Vita. |
And yes, Meta did name their Android-VR operating system with the exact same name, but I guess the name wasn't ever marketed with regards to the consoles. Edit: mentioning @ian-h-chamberlain @AzureMarker for good measure. |
Hi, Vita target does not implement
It's gated in the header under See |
Ah, damn. :/ Is there an issue tracker where one could ask for better POSIX coverage? EDIT: I guess that's the mailing list mentioned here. |
Ironically, "winsup" has posix_memalign. Also ironically, it does have |
This comment was marked as resolved.
This comment was marked as resolved.
Oh, right! We could probably use comments in our code or the platform support documentation to that effect. It is possible these already exist and I just missed it. |
To motivate requests like Ralf's somewhat for the target maintainers:
People have been implementing more shims for Miri. The more the stdlib flows through standard, well-specified functions, the more Miri doesn't have to have a huge pile of ridiculous hacks. This allows even code for more... interesting platforms, that do basic interop with the system (we're not gonna be simulating games with full rendering to a framebuffer, here...) to benefit from Miri's ability to execute code on the Rust Abstract Machine, either simply as a (slow, but effective) virtual machine, or for its ability to detect violated invariants. Thus if you rely on an upstream C library, and that C library can be persuaded to gain (or simply PRed) extended support for "core" POSIX or Standard C functions... conformant support... this can reduce the amount of maintenance everyone has to do in the future, by making it easier to debug problems with your platform. Correctly-aligned allocations are pretty important, since people can request arbitrary layouts are allocated with Rust code. They do use that to good effect, and it turns out that |
Hm, |
Okie-dokie, had been giving it a few days to see if any of the other pinged maintainers had something to say, but we have harder evidence for the Redox and Espressif changes being correct and tier 3 is alas tier 3. Rolling ahead with this. @bors r+ |
@bors rollup |
…jubilee use posix_memalign on almost all Unix targets Seems nice to be able to use a single common codepath for all of them. :) The `libc` crate says this symbol exists for all Unix targets. I did locally do check-builds to ensure this still builds, but I can't really test more than that. - For redox, I found indications posix_memalign really exists [here](https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/271) - For esp-idf, I found indications [here](playable-tech/esp-idf@c5b297a) - ~~For horizon and vita (these seem to be gaming console OSes? "Horizon OS" also has some hits for a Facebook product but that seems unrelated), they seem to be based on "newlib", where posix_memalign [seems to exist](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3ba2c39fb2a12cd7332ef16b1b3e3df994f7c6f5).~~ Turns out no, this 20-year-old standard POSIX function is unfortunately [not supported](rust-lang#125271 (comment)) here.
…kingjubilee Rollup of 9 pull requests Successful merges: - rust-lang#124080 (Some unstable changes to where opaque types get defined) - rust-lang#125271 (use posix_memalign on almost all Unix targets) - rust-lang#125433 (A small diagnostic improvement for dropping_copy_types) - rust-lang#125498 (Stop using the avx512er and avx512pf x86 target features) - rust-lang#125510 (remove proof tree formatting, make em shallow) - rust-lang#125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate) - rust-lang#125514 (Structurally resolve before `builtin_index` in EUV) - rust-lang#125515 ( bootstrap: support target specific config overrides ) - rust-lang#125527 (Add manual Sync impl for ReentrantLockGuard) r? `@ghost` `@rustbot` modify labels: rollup
…jubilee use posix_memalign on almost all Unix targets Seems nice to be able to use a single common codepath for all of them. :) The `libc` crate says this symbol exists for all Unix targets. I did locally do check-builds to ensure this still builds, but I can't really test more than that. - For redox, I found indications posix_memalign really exists [here](https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/271) - For esp-idf, I found indications [here](playable-tech/esp-idf@c5b297a) - ~~For horizon and vita (these seem to be gaming console OSes? "Horizon OS" also has some hits for a Facebook product but that seems unrelated), they seem to be based on "newlib", where posix_memalign [seems to exist](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3ba2c39fb2a12cd7332ef16b1b3e3df994f7c6f5).~~ Turns out no, this 20-year-old standard POSIX function is unfortunately [not supported](rust-lang#125271 (comment)) here.
…kingjubilee Rollup of 7 pull requests Successful merges: - rust-lang#125271 (use posix_memalign on almost all Unix targets) - rust-lang#125433 (A small diagnostic improvement for dropping_copy_types) - rust-lang#125498 (Stop using the avx512er and avx512pf x86 target features) - rust-lang#125510 (remove proof tree formatting, make em shallow) - rust-lang#125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate) - rust-lang#125514 (Structurally resolve before `builtin_index` in EUV) - rust-lang#125527 (Add manual Sync impl for ReentrantLockGuard) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#125271 (use posix_memalign on almost all Unix targets) - rust-lang#125451 (Fail relating constants of different types) - rust-lang#125478 (Bump bootstrap compiler to the latest beta compiler) - rust-lang#125498 (Stop using the avx512er and avx512pf x86 target features) - rust-lang#125510 (remove proof tree formatting, make em shallow) - rust-lang#125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate) - rust-lang#125514 (Structurally resolve before `builtin_index` in EUV) - rust-lang#125527 (Add manual Sync impl for ReentrantLockGuard) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#125271 - RalfJung:posix_memalign, r=workingjubilee use posix_memalign on almost all Unix targets Seems nice to be able to use a single common codepath for all of them. :) The `libc` crate says this symbol exists for all Unix targets. I did locally do check-builds to ensure this still builds, but I can't really test more than that. - For redox, I found indications posix_memalign really exists [here](https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/271) - For esp-idf, I found indications [here](playable-tech/esp-idf@c5b297a) - ~~For horizon and vita (these seem to be gaming console OSes? "Horizon OS" also has some hits for a Facebook product but that seems unrelated), they seem to be based on "newlib", where posix_memalign [seems to exist](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3ba2c39fb2a12cd7332ef16b1b3e3df994f7c6f5).~~ Turns out no, this 20-year-old standard POSIX function is unfortunately [not supported](rust-lang#125271 (comment)) here.
Seems nice to be able to use a single common codepath for all of them. :) The
libc
crate says this symbol exists for all Unix targets. I did locally do check-builds to ensure this still builds, but I can't really test more than that.For horizon and vita (these seem to be gaming console OSes? "Horizon OS" also has some hits for a Facebook product but that seems unrelated), they seem to be based on "newlib", where posix_memalign seems to exist.Turns out no, this 20-year-old standard POSIX function is unfortunately not supported here.