add aarch64_unknown_nto_qnx700 target - QNX 7.0 support for aarch64le

[nyurik]

This backports the 7.1 implementation to 7.0.

• required -lregex disabled, see Disable libregex for QNX 7.0 libc#3775 (released in libc 0.2.156)
• uses libgcc.a instead of libgcc_s.so (7.0 used ancient GCC 5.4 which didn't have gcc_s)
• [optional] a fix in backtrace crate to support stack traces Add QNX NTO platform support backtrace-rs#648

CC: to the folks who did the initial implementation: @flba-eb, @gh-tr, @jonathanpallant, @japaric

Use latest libc

Either use libc 0.2.156+, or do these steps:

• In the rust/Cargo.toml, add this line to the [patch.crates-io] section. This version is based on v0.2.155 libc release plus the needed changes from Disable libregex for QNX 7.0 libc#3775

[patch.crates-io]
libc = { git = "https://github.com/rust-lang/libc.git", rev = "59890b5addd109b47da733c3ce32d7e7e7542811" }

• in the rust/config.toml, add these lines:

[rust]
deny-warnings = false

• run cargo update -p libc in the rust repo's root

Compile target

source /path/to/qnx7.0/qnxsdp-env.sh

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'

env $build_env \
    ./x.py build \
        --target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \
        rustc library/core library/alloc library/std

rustup toolchain link stage1 build/host/stage1

Compile "hello world"

source /path/to/qnx7.0/qnxsdp-env.sh

cargo new hello_world
cd hello_world
cargo +stage1 build --release --target aarch64-unknown-nto-qnx700

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[TaKO8Ki]

@rustbot author

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[nyurik]

@TaKO8Ki I think this PR is ready - as it can be merged without waiting for libc. Thx!

[nyurik]

@rustbot ready

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Nilstrieb

[jonathanpallant]

I got a 7.0 license so I can give this a spin in the next week or so.

[nyurik]

Thx @jonathanpallant! I was able to build and run martin's -p mbtiles tool - which uses 300+ packages, including the just released tokio with mio 1.0 qnx support and bundling sqlite code - and it all ran flawlessly without any changes.

[nyurik]

I was able to run compiler tests, having to do some workarounds, and got 13225 passed; 3792 failed; 293 ignored; 57 filtered out (filter are the ones listed here). Running it again produced identical failure count. --sequential serever listener ran much faster.

To run, I had to add this line at the end in Cargo.toml's patch section: libc = { git = "https://github.com/rust-lang/libc.git", rev = "59890b5addd109b47da733c3ce32d7e7e7542811" } and use --skip src/tools/tidy, or else tidy was failing at the start.

Most errors show this cryptic error: client.read_exact(&mut header) failed with failed to fill whole buffer.
The remote executor shows a lot of these messages:

thread '<unnamed>' panicked at src/tools/remote-test-server/src/main.rs:299:13:
cmd.stdin(Stdio::null()).stdout(Stdio::piped()).stderr(Stdio::piped()).spawn() failed with Exec format error (os error 8)

[jonathanpallant]

I was able to build the target with the instructions above (although I note the libc crate warnings are a little troubling...). Now I just need to work out how to make a QNX Neutrino 7.0 disk image I can boot in QEMU.

$ bash -c 'source ~/qnx700/qnxsdp-env.sh && cargo +stage1 build --target=aarch64-unknown-nto-qnx700 && file ./target/aarch64-unknown-nto-qnx700/debug/simpletest'
QNX_HOST=/Users/jonathan/qnx700/host/darwin/x86_64
QNX_TARGET=/Users/jonathan/qnx700/target/qnx7
MAKEFLAGS=-I/Users/jonathan/qnx700/target/qnx7/usr/include
   Compiling simpletest v0.1.0 (/Users/jonathan/simpletest)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.44s
./target/aarch64-unknown-nto-qnx700/debug/simpletest: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /usr/lib/ldqnx-64.so.2, BuildID[md5/uuid]=ffd4b4fcd60ead8f6b41e5c64aec8ba4, with debug_info, not stripped

[nyurik]

Full testing notes, some of which may go into qnx md page:

Build compiler

# Configure qcc build environment
source _path_/qnx700/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

Configure remote

Do this from a new shell - we will need to run more commands in the previous one. I ran into these two issues.

• 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.

# 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

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

[nyurik]

Using the above method and a properly configured QNX 7.0, I got all but one test to pass: [ui] tests/ui/structs-enums/enum-rec/issue-17431-6.rs. See #127897 (comment)

Fixed Test

• without /etc/hosts, this test is unable to resolve localhost. Test with "127.0.0.1" is OK
  • [ui] tests/ui/threads-sendsync/sync-send-in-std.rs
• these tests are due to missing head utility on the remote. Once added, passes OK.
• [ui] tests/ui/process/println-with-broken-pipe.rs
• [ui] tests/ui/process/process-sigpipe.rs
• All these tests are fixed with Add QNX NTO platform support backtrace-rs#648
  • [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

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[nyurik]

Digging deep into backtracing, at first it appeared as if it was simply disabled for QNX 7.0 by @samkearney in rust-lang/backtrace-rs#529, but re-enabling it produced the same test results (but has compiled without any issues). The original PR note:

The QNX Neutrino 7.0 target ships a toolchain without a native unwinder implementation. libgcc with unwinding symbols is present in version 7.1 and newer, which is why 7.0 is the only version called out here.

I looked through both 7.0 and 7.1, and they do not appear any different - so not certain where that info came from. I am not certain this is a real block (most code would never care about parsing backtraces), but it does fail some unit tests.

Any thoughts are welcome...

[samkearney]

@nyurik This was a while back, but I am fairly sure I couldn't get it to compile when I was trying it with 7.0, and was getting linker errors for the unwinding-related functions. But since you got it to compile it's evident that I was missing something, so I would discard my comment from before. It's worth noting that I was working only with x86 (32-bit) and didn't try aarch64. Unfortunately, since I did not get to the point of running tests, I don't have any insight on the test failures.

[nyurik]

@samkearney I just got all backtrace support to work as part of the rust-lang/backtrace-rs#648 -- note that it is using very new way to parse the stacktrace - it might be that the core code in that crate has changed its approach, and now it works? If you have a QNX x86 7.0 that I can ssh into, I could try to check the x86. Lets connect on https://rust-lang.zulipchat.com/ and discuss it there? In the mean time, any code review or a +1 would be great :)

[nyurik]

IMO, this is not a blocker for merging

The [ui] tests/ui/structs-enums/enum-rec/issue-17431-6.rs #17431 test is the last one to keep failing. It is NOT a blocker because the incorrect code produces similar but not identical errors for the platform. It might be worth investigating because I would have expected the compiler to validate recursive struct definitions identically regardless of the target. I copy/pasted that file into a separate project and compiled it using linux and qnx targets. Red is the output targeting linux, Green is the output of the compiler when targeting QNX.

use std::sync::Mutex;
enum Foo { X(Mutex<Option<Foo>>) }
impl Foo { fn bar(self) {} }
fn main() {}

 error[E0072]: recursive type `Foo` has infinite size
   --> src/main.rs:28:1
    |
 28 | enum Foo { X(Mutex<Option<Foo>>) }
    | ^^^^^^^^                  --- recursive without indirection
    |
 help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle
    |
 28 | enum Foo { X(Mutex<Option<Box<Foo>>>) }
    |                           ++++   +
 
-error[E0391]: cycle detected when computing when `Foo` needs drop
-  --> src/main.rs:28:1
-   |
-28 | enum Foo { X(Mutex<Option<Foo>>) }
-   | ^^^^^^^^
-   |
-   = note: ...which immediately requires computing when `Foo` needs drop again
-   = note: cycle used when computing whether `Foo` needs drop

+error[E0391]: cycle detected when computing layout of `Foo`
+   |
+   = note: ...which requires computing layout of `std::sync::mutex::Mutex<core::option::Option<Foo>>`...
+   = note: ...which requires computing layout of `core::cell::UnsafeCell<core::option::Option<Foo>>`...
+   = note: ...which requires computing layout of `core::option::Option<Foo>`...
+   = note: ...which again requires computing layout of `Foo`, completing the cycle
+note: cycle used when elaborating drops for `<impl at src/main.rs:30:1: 30:9>::bar`
+  --> src/main.rs:30:12
+   |
+30 | impl Foo { fn bar(self) {} }
+   |            ^^^^^^^^^^^^

    = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information
 
 Some errors have detailed explanations: E0072, E0391.
 For more information about an error, try `rustc --explain E0072`.
 error: could not compile `btdbg` (bin "btdbg") due to 2 previous errors

CC: @isabelmu as the author of the #17815 fix

[nyurik]

@TaKO8Ki hi, are there any blockers to merge this?

[nyurik]

Previous QNX PRs and their reviewers, in case they have any feedback or want to review and merge this:

• Add tier 3 no_std AArch64/x86_64 support for the QNX Neutrino RTOS #102701 @cjgillot
• Add tier 3 no_std x86 support for QNX Neutrino RTOS, version 7.0 #109173 @compiler-errors