Add QNX NTO platform support #648

nyurik · 2024-08-01T21:54:02Z

Part of adding aarch64-unknown-nto-qnx700 support to Rust. This will resolve the following failing unit tests:

[ui] tests/ui/backtrace/backtrace.rs
[ui] tests/ui/backtrace/dylib-dep.rs
[ui] tests/ui/backtrace/line-tables-only.rs
[ui] tests/ui/backtrace/std-backtrace.rs
[ui] tests/ui/panics/issue-47429-short-backtraces.rs#legacy
[ui] tests/ui/panics/issue-47429-short-backtraces.rs#v0
[ui] tests/ui/panics/runtime-switch.rs#legacy
[ui] tests/ui/panics/runtime-switch.rs#v0
[ui] tests/ui/panics/short-ice-remove-middle-frames-2.rs
[ui] tests/ui/panics/short-ice-remove-middle-frames.rs
[ui] tests/ui/runtime/backtrace-debuginfo.rs

workingjubilee · 2024-08-02T23:18:04Z

src/symbolize/gimli/libs_dl_iterate_phdr.rs

+// On `QNX-NTO` platform, info is a const pointer
 unsafe extern "C" fn callback(
-    info: *mut libc::dl_phdr_info,
+    #[cfg(not(target_os = "nto"))] info: *mut libc::dl_phdr_info,
+    #[cfg(target_os = "nto")] info: *const libc::dl_phdr_info,


@workingjubilee because otherwise compiler complains that the declaration in the Rust code does not match C header files. I had to make this change in order to get it to compile, which resulted in stack traces to start working on QNX. 🤷

which compiler?

rustc can't read a C header file, and the C compilers don't know how to read Rust code, so what's actually emitting the error?

@workingjubilee I suspect libc crate actually runs bindgen, and this is where it breaks. I am doing the steps I described here, and if i revert these specific lines, I get this error while building a compiler.

P.S. I am using the compiler and the headers that ship with QNX 7.0

error[E0308]: mismatched types --> library/std/src/../../backtrace/src/symbolize/gimli/libs_dl_iterate_phdr.rs:15:36 | 15 | libc::dl_iterate_phdr(Some(callback), core::ptr::addr_of_mut!(ret).cast()); | ---- ^^^^^^^^ types differ in mutability | | | arguments to this enum variant are incorrect | = note: expected fn pointer `unsafe extern "C" fn(*const dl_phdr_info, _, _) -> _` found fn item `unsafe extern "C" fn(*mut dl_phdr_info, _, _) -> _ {callback}` help: the type constructed contains `unsafe extern "C" fn(*mut dl_phdr_info, usize, *mut libc::c_void) -> i32 {callback}` due to the type of the argument passed --> library/std/src/../../backtrace/src/symbolize/gimli/libs_dl_iterate_phdr.rs:15:31 | 15 | libc::dl_iterate_phdr(Some(callback), core::ptr::addr_of_mut!(ret).cast()); | ^^^^^--------^ | | | this argument influences the type of `Some` note: tuple variant defined here --> /home/nyurik/dev/rust/rust/library/core/src/option.rs:579:5 | 579 | Some(#[stable(feature = "rust1", since = "1.0.0")] T), | ^^^^ For more information about this error, try `rustc --explain E0308`. error: could not compile `std` (lib) due to 1 previous error Build completed unsuccessfully in 0:07:01

I'm surprised to learn that *const T and *mut T are ABI compatible, this would have saved me some work when implementing the libc and abstraction layers.
However, I'm not sure if I would have walked this way: I agree with @nyurik that the C header files are the source of truth and that the libc crate should define the same functions with exact same signatures as their C counterpart. In my opinion, it is the job of the abstraction layers to abstract from such differences.

As for staying compatible with the 2 years old QNX introduction: I would not mind changing it in an incompatible way to e.g. match the C counterpart, i.e. to fix a discrepancy between libc-crate and libc-header. But changing it so that it is deviating sounds more like introducing a bug.

I don't think that there are more than a few dozens Rust@QNX users out there, and the number of those who are using dl_iterate_phdr should be near to 2 ...

I think there are likely to be approximately zero users of this API in libc on QNX, such that changing libc to use *mut on QNX (matching other platforms) will not in practice break anyone. And better to normalize in libc than in every user of libc.

@flba-eb @nyurik I am happy to lose the argument about whether or not libc should change, but you may reconsider on seeing some of my alternatives, because they may involve mem::transmute. Or as casts, which are honestly about as bad.

You see, the issue is visible in this code sample:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7208c770e9303755778a9ac0bb6535df

Notice how <*mut T>::cast_mut doesn't exist? And <*const T>::cast_const also doesn't. And fixing this fact requires a bunch of extension code. So a transmute starts to be the easiest way out.

@workingjubilee thx, see rust-lang/libc#3792 - there are some CI issues with libc, but once resolved, @joshtriplett is ok to merge (and hopefully release soon). Hopefully we can resolve this soon thereafter.

One question - since this change will only be in libc 0.2.156+, this PR will have to also bump Cargo.toml's minimal libc to that same version. Is this how you want to proceed with this PR?

Yes, bumping to that libc is fine.

All other platforms use `* mut`, and while this is technically a breaking change, most likely noone is using it directly. See also rust-lang/backtrace-rs#648

Modify QNX NTO `dl_iterate_phdr` to toke `* mut` All other platforms use `* mut`, and while this is technically a breaking change, most likely noone is using it directly. NTO does not define last four fields of the `dl_phdr_info`, so might as well exclude them for cleanliness. v7.0: [link](https://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.neutrino.lib_ref/topic/d/dl_iterate_phdr.html) v7.1: [link](https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.lib_ref/topic/d/dl_iterate_phdr.html) v8.0: [link](https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.lib_ref/topic/d/dl_iterate_phdr.html?hl=dl_phdr_info) See also rust-lang/backtrace-rs#648

Modify QNX NTO `dl_iterate_phdr` to toke `* mut` All other platforms use `* mut`, and while this is technically a breaking change, most likely noone is using it directly. NTO does not define last four fields of the `dl_phdr_info`, so might as well exclude them for cleanliness. v7.0: [link](https://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.neutrino.lib_ref/topic/d/dl_iterate_phdr.html) v7.1: [link](https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.lib_ref/topic/d/dl_iterate_phdr.html) v8.0: [link](https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.lib_ref/topic/d/dl_iterate_phdr.html?hl=dl_phdr_info) See also rust-lang/backtrace-rs#648 (backport <rust-lang#3815>) (cherry picked from commit 4edd266)

nyurik · 2024-08-15T20:36:26Z

@workingjubilee thx for all the feedback, libc 0.2.156 just released with the consistent backtrace on QNX. I updated this PR to use it.

nyurik · 2024-08-25T01:10:12Z

@workingjubilee thx, fixed merge conflict, should be ok now

add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le This backports the QNX 7.1 aarch64 implementation to 7.0. * [x] required `-lregex` disabled, see rust-lang/libc#3775 (released in libc 0.2.156) * [x] uses `libgcc.a` instead of `libgcc_s.so` (7.0 used ancient GCC 5.4 which didn't have gcc_s) * [x] a fix in `backtrace` crate to support stack traces rust-lang/backtrace-rs#648 This PR bumps libc dependency to 0.2.158 CC: to the folks who did the [initial implementation](https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html): `@flba-eb,` `@gh-tr,` `@jonathanpallant,` `@japaric` # Compile target ```bash # Configure qcc build environment source _path_/_to_/qnx7.0/qnxsdp-env.sh # Tell rust to use qcc when building QNX 7.0 targets export build_env=' CC_aarch64-unknown-nto-qnx700=qcc CFLAGS_aarch64-unknown-nto-qnx700=-Vgcc_ntoaarch64le_cxx CXX_aarch64-unknown-nto-qnx700=qcc AR_aarch64_unknown_nto_qnx700=ntoaarch64-ar' # Build rust compiler, libs, and the remote test server env $build_env ./x.py build \ --target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \ rustc library/core library/alloc library/std src/tools/remote-test-server rustup toolchain link stage1 build/host/stage1 ``` # Compile "hello world" ```bash source _path_/_to_/qnx7.0/qnxsdp-env.sh cargo new hello_world cd hello_world cargo +stage1 build --release --target aarch64-unknown-nto-qnx700 ``` # Configure a remote for testing Do this from a new shell - we will need to run more commands in the previous one. I ran into these two issues, and found some workarounds. * Temporary dir might not work properly * Default `remote-test-server` has issues binding to an address ``` # ./remote-test-server starting test server thread 'main' panicked at src/tools/remote-test-server/src/main.rs:175:29: called `Result::unwrap()` on an `Err` value: Os { code: 249, kind: AddrNotAvailable, message: "Can't assign requested address" } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` Specifying `--bind` param actually fixes that, and so does setting `TMPDIR` properly. ```bash # Copy remote-test-server to remote device. You may need to use sftp instead. # ATTENTION: Note that the path is different from the one in the remote testing documentation for some reason scp ./build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server qnxdevice:/path/ # Run ssh with port forwarding - so that rust tester can connect to the local port instead ssh -L 12345:127.0.0.1:12345 qnxdevice # on the device, run rm -rf tmp && mkdir -p tmp && TMPDIR=$PWD/tmp ./remote-test-server --bind 0.0.0.0:12345 ``` # Run test suit Assume all previous environment variables are still set, or re-init them ```bash export TEST_DEVICE_ADDR="localhost:12345" # tidy needs to be skipped due to using un-published libc dependency export exclude_tests=' --exclude src/bootstrap --exclude src/tools/error_index_generator --exclude src/tools/linkchecker --exclude src/tools/tidy --exclude tests/ui-fulldeps --exclude rustc --exclude rustdoc --exclude tests/run-make-fulldeps' env $build_env ./x.py test $exclude_tests --stage 1 --target aarch64-unknown-nto-qnx700 ```

add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le This backports the QNX 7.1 aarch64 implementation to 7.0. * [x] required `-lregex` disabled, see rust-lang/libc#3775 (released in libc 0.2.156) * [x] uses `libgcc.a` instead of `libgcc_s.so` (7.0 used ancient GCC 5.4 which didn't have gcc_s) * [x] a fix in `backtrace` crate to support stack traces rust-lang/backtrace-rs#648 This PR bumps libc dependency to 0.2.158 CC: to the folks who did the [initial implementation](https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html): `@flba-eb,` `@gh-tr,` `@jonathanpallant,` `@japaric` # Compile target ```bash # Configure qcc build environment source _path_/_to_/qnx7.0/qnxsdp-env.sh # Tell rust to use qcc when building QNX 7.0 targets export build_env=' CC_aarch64-unknown-nto-qnx700=qcc CFLAGS_aarch64-unknown-nto-qnx700=-Vgcc_ntoaarch64le_cxx CXX_aarch64-unknown-nto-qnx700=qcc AR_aarch64_unknown_nto_qnx700=ntoaarch64-ar' # Build rust compiler, libs, and the remote test server env $build_env ./x.py build \ --target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \ rustc library/core library/alloc library/std src/tools/remote-test-server rustup toolchain link stage1 build/host/stage1 ``` # Compile "hello world" ```bash source _path_/_to_/qnx7.0/qnxsdp-env.sh cargo new hello_world cd hello_world cargo +stage1 build --release --target aarch64-unknown-nto-qnx700 ``` # Configure a remote for testing Do this from a new shell - we will need to run more commands in the previous one. I ran into these two issues, and found some workarounds. * Temporary dir might not work properly * Default `remote-test-server` has issues binding to an address ``` # ./remote-test-server starting test server thread 'main' panicked at src/tools/remote-test-server/src/main.rs:175:29: called `Result::unwrap()` on an `Err` value: Os { code: 249, kind: AddrNotAvailable, message: "Can't assign requested address" } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` Specifying `--bind` param actually fixes that, and so does setting `TMPDIR` properly. ```bash # Copy remote-test-server to remote device. You may need to use sftp instead. # ATTENTION: Note that the path is different from the one in the remote testing documentation for some reason scp ./build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server qnxdevice:/path/ # Run ssh with port forwarding - so that rust tester can connect to the local port instead ssh -L 12345:127.0.0.1:12345 qnxdevice # on the device, run rm -rf tmp && mkdir -p tmp && TMPDIR=$PWD/tmp ./remote-test-server --bind 0.0.0.0:12345 ``` # Run test suit Assume all previous environment variables are still set, or re-init them ```bash export TEST_DEVICE_ADDR="localhost:12345" # tidy needs to be skipped due to using un-published libc dependency export exclude_tests=' --exclude src/bootstrap --exclude src/tools/error_index_generator --exclude src/tools/linkchecker --exclude src/tools/tidy --exclude tests/ui-fulldeps --exclude rustc --exclude rustdoc --exclude tests/run-make-fulldeps' env $build_env ./x.py test $exclude_tests --stage 1 --target aarch64-unknown-nto-qnx700 ``` try-job: dist-x86_64-msvc

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [backtrace](https://redirect.github.com/rust-lang/backtrace-rs) | dependencies | patch | `0.3.73` -> `0.3.74` | | [backtrace](https://redirect.github.com/rust-lang/backtrace-rs) | dev-dependencies | patch | `0.3.73` -> `0.3.74` | --- ### Release Notes <details> <summary>rust-lang/backtrace-rs (backtrace)</summary> ### [`v0.3.74`](https://redirect.github.com/rust-lang/backtrace-rs/releases/tag/0.3.74) [Compare Source](https://redirect.github.com/rust-lang/backtrace-rs/compare/0.3.73...0.3.74) #### What's Changed - QNX Neutrino 7.0 support, thanks to [@nyurik](https://redirect.github.com/nyurik) in [rust-lang/backtrace-rs#648 - Cleaned up our Android support. This should massively improve backtraces for ones with the API level sufficient to ship with libunwind, etc. Unfortunately, it comes at the cost of dropping support for older ones! Thanks to [@fengys](https://redirect.github.com/fengys) in [rust-lang/backtrace-rs#656 - Made PrintFmt, which was using the `Enum::__NonExhaustiveVariant` pattern, use `#[non_exhaustive]` for real. Don't @ me if you were matching on that! Thanks to [@nyurik](https://redirect.github.com/nyurik) in [rust-lang/backtrace-rs#651 - Massively cleaned up the windows code! We moved from winapi to windows-sys with windows-targets thanks to [@CraftSpider](https://redirect.github.com/CraftSpider) and [@ChrisDenton](https://redirect.github.com/ChrisDenton) in - Don't cast HANDLE to usize and back by [@CraftSpider](https://redirect.github.com/CraftSpider) in [rust-lang/backtrace-rs#635 - Switch from `winapi` to `windows-sys` by [@CraftSpider](https://redirect.github.com/CraftSpider) in [rust-lang/backtrace-rs#641 - Update windows bindings and use windows-targets by [@ChrisDenton](https://redirect.github.com/ChrisDenton) in [rust-lang/backtrace-rs#653 - A bunch of updated dependencies. Thanks [@djc](https://redirect.github.com/djc) and [@khuey](https://redirect.github.com/khuey)! - Sorry if you were testing this code in miri! It started yelling about sussy casts. A lot. We did a bunch of internal cleanups that should make it quiet down, thanks to [@workingjubilee](https://redirect.github.com/workingjubilee) in [rust-lang/backtrace-rs#641 - Uhhh we had to tweak `dl_iterate_phdr` in [rust-lang/backtrace-rs#660 after Android revealed it was... kind of unsound actually and not doing things like checking for null pointers before making slices! WHOOPS! Thanks to [@saethlin](https://redirect.github.com/saethlin) for implementing detection for precisely that in rustc! It's really hard to find soundness issues in inherited codebases like this one... #### New Contributors - [@CraftSpider](https://redirect.github.com/CraftSpider) made their first contribution in [rust-lang/backtrace-rs#635 - [@fengys1996](https://redirect.github.com/fengys1996) made their first contribution in [rust-lang/backtrace-rs#656 - [@djc](https://redirect.github.com/djc) made their first contribution in [rust-lang/backtrace-rs#657 **Full Changelog**: rust-lang/backtrace-rs@0.3.73...0.3.74 </details> --- ### Configuration 📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone America/New_York, Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- Release Notes: - N/A  Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

nyurik force-pushed the nto-fix branch from c928e12 to 64cbb2b Compare August 1, 2024 22:04

nyurik mentioned this pull request Aug 1, 2024

add aarch64_unknown_nto_qnx700 target - QNX 7.0 support for aarch64le rust-lang/rust#127897

Merged

3 tasks

workingjubilee reviewed Aug 2, 2024

View reviewed changes

nyurik added a commit to nyurik/libc that referenced this pull request Aug 5, 2024

Modify QNX NTO dl_iterate_phdr to toke * mut

22d54ff

All other platforms use `* mut`, and while this is technically a breaking change, most likely noone is using it directly. See also rust-lang/backtrace-rs#648

nyurik mentioned this pull request Aug 5, 2024

Modify QNX NTO dl_iterate_phdr to take * mut rust-lang/libc#3792

Closed

nyurik mentioned this pull request Aug 13, 2024

Modify QNX NTO platform support rust-lang/libc#3790

Closed

nyurik force-pushed the nto-fix branch from 64cbb2b to 3186fa1 Compare August 15, 2024 20:35

workingjubilee added the S-merge-conflicts label Aug 24, 2024

Add QNX NTO platform support

cbb3da2

nyurik force-pushed the nto-fix branch from 3186fa1 to cbb3da2 Compare August 25, 2024 01:09

workingjubilee removed the S-merge-conflicts label Aug 27, 2024

workingjubilee approved these changes Aug 27, 2024

View reviewed changes

workingjubilee merged commit 600beaa into rust-lang:master Aug 27, 2024
41 checks passed

nyurik deleted the nto-fix branch August 27, 2024 02:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add QNX NTO platform support #648

Add QNX NTO platform support #648

nyurik commented Aug 1, 2024 •

edited by workingjubilee

Loading

workingjubilee Aug 2, 2024

nyurik Aug 2, 2024

workingjubilee Aug 2, 2024

workingjubilee Aug 2, 2024

nyurik Aug 2, 2024 •

edited

Loading

flba-eb Aug 5, 2024

joshtriplett Aug 5, 2024

workingjubilee Aug 6, 2024

nyurik Aug 8, 2024

workingjubilee Aug 24, 2024

nyurik commented Aug 15, 2024

nyurik commented Aug 25, 2024

Add QNX NTO platform support #648

Add QNX NTO platform support #648

Conversation

nyurik commented Aug 1, 2024 • edited by workingjubilee Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nyurik Aug 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nyurik commented Aug 15, 2024

nyurik commented Aug 25, 2024

nyurik commented Aug 1, 2024 •

edited by workingjubilee

Loading

nyurik Aug 2, 2024 •

edited

Loading