Support QNX 7.1 with io-sock+libstd and QNX 8.0 (no_std only)

[flba-eb]

Changes of this pull request:

1. Refactor code for qnx nto targets to share more code in file nto_qnx.rs

2. Add support for an additional network stack on nto qnx 7.1.

   QNX 7.1 supports two network stacks:

   1. io-pkt, which is default
   2. io-sock, which is optional on 7.1 but default in QNX 8.0

   As one can see in the io-sock migration notes, this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.

   This change adds a new target which has a different value for target_env, so that e.g. libc can distinguish between both APIs.

3. Add initial support for QNX 8.0, thanks @AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for target_env anymore).

@rustbot label +O-neutrino
CC: @jonathanpallant @japaric @gh-tr @AkhilTThomas

[rustbot]

r? @pnkfelix

rustbot has assigned @pnkfelix.
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

[jonathanpallant]

So, first up, excellent! The AWS QNX Neutrino 7.1.0 AMIs appears to use iosock and so I have to keep copying over libsocket.so.3 to run Rust code there. With this change hopefully I won't.

However, I note that there are currently no five-part-triples in the target list, so this would be the first. Perhaps aarch64-unknown-nto-qnx710_iosock would be better.

Will there be a x86_64-unknown-nto-qnx710_iosock to match?

[flba-eb]

So, first up, excellent! The AWS QNX Neutrino 7.1.0 AMIs appears to use iosock and so I have to keep copying over libsocket.so.3 to run Rust code there. With this change hopefully I won't.

Beware that version 3 and 4 have different APIs -- they may seem to work, but there might be subtle issues up to undefined behavior.

However, I note that there are currently no five-part-triples in the target list, so this would be the first. Perhaps aarch64-unknown-nto-qnx710_iosock would be better.

Very good idea -- I found it confusing that target_env uses an underscore while the target name does not. I will rename it!

Will there be a x86_64-unknown-nto-qnx710_iosock to match?

Not planned so far, but should be quite easy to do. How big is the need for it?

[jonathanpallant]

How big is the need for it?

No idea. Who was asking for this target?

[jonathanpallant]

I was thinking to use an obvious dummy value rather than panicking if the environment variable isn't set. But maybe the project people have a better idea.

Are there another other targets that need to read environment variables?

[flba-eb]

As @pnkfelix left the compiler team, I would like to kindly ask @workingjubilee if they could have a look at this PR 😄 🎄 🎉

r? @workingjubilee

[jonathanpallant]

On Windows 10, I get:

C:\Users\JonathanPallant\Documents\rust>C:\Users\JonathanPallant\AppData\Roaming\uv\python\cpython-3.13.1-windows-x86_64-none\python.exe .\x.py build --target=x86_64-pc-windows-msvc,x86_64-pc-nto-qnx800 rustc library/core library/alloc library/std

...

error occurred: unknown target `x86_64-pc-nto-qnx800`

Ah, do I still have to patch cc-rs?

[jonathanpallant]

I patched cc-rs and it still doesn't know about QNX Neutrino 8.0. What's the best way to build this target right now?

[AkhilTThomas]

I patched cc-rs and it still doesn't know about QNX Neutrino 8.0. What's the best way to build this target right now?

The patch i use is below.
However since generated.rs is generated this change is removed. details

diff --git a/src/target/generated.rs b/src/target/generated.rs
index 0c9b0ae..103bf36 100644
--- a/src/target/generated.rs
+++ b/src/target/generated.rs
@@ -352,6 +352,18 @@ pub(crate) const LIST: &[(&str, TargetInfo<'static>)] = &[
             unversioned_llvm_target: "aarch64-unknown-unknown",
         },
     ),
+    (
+        "aarch64-unknown-nto-qnx800",
+        TargetInfo {
+            full_arch: "aarch64",
+            arch: "aarch64",
+            vendor: "unknown",
+            os: "nto",
+            env: "nto80",
+            abi: "",
+            unversioned_llvm_target: "aarch64-unknown-unknown",
+        },
+    ),
     (
         "aarch64-unknown-openbsd",
         TargetInfo {
@@ -2896,6 +2908,18 @@ pub(crate) const LIST: &[(&str, TargetInfo<'static>)] = &[
             unversioned_llvm_target: "x86_64-pc-unknown",
         },
     ),
+    (
+        "x86_64-pc-nto-qnx800",
+        TargetInfo {
+            full_arch: "x86_64",
+            arch: "x86_64",
+            vendor: "pc",
+            os: "nto",
+            env: "nto80",
+            abi: "",
+            unversioned_llvm_target: "x86_64-pc-unknown",
+        },
+    ),

[jonathanpallant]

OK, I got the QNX Neutrino 8.0 target for x86-64 compiled, but the linker is complaining about undefined reference to __my_thread_exit'`.

Do I need libc patches or something? Have the QNX Neutrino 8.0 targets been compiled/tested and if so, on which platforms were they tested?

[AkhilTThomas]

OK, I got the QNX Neutrino 8.0 target for x86-64 compiled, but the linker is complaining about undefined reference to __my_thread_exit'`.

This is known (chicken and egg problem 🐔 🥚) , this can only be solved with a patch on libc , which currently gates these behind the target_env.

Do I need libc patches or something? Have the QNX Neutrino 8.0 targets been compiled/tested and if so, on which platforms were they tested?

I have compiled and run both aarch64 and x86-64 on qemu. I'm not aware of how to generate a nice report. (Please let me know if there is a way)
I'm attaching the reports on

• x86-64 test_x86-64.log
• aarch64 test_aarch64.log

My understanding is that once the targets are available here the libc changes can be pushed.

[jonathanpallant]

Can you post a gist with a list of steps to reproduce so I can verify? Sounds like I need to point to a local copy of cc-rs with some patches (maybe someone can push those somewhere so we can see them ahead of the targets being regenerated) and a patch to point to a local copy of libc (or again, can someone push that somewhere).

In the absence of the Rust Project being able to build these targets in CI, I think it's important that the maintainers can at least verify that the target builds OK, and currently I cannot.

[jonathanpallant]

Also, heads up - tomorrow is my last day of work in 2024, so if I can't do a build tomorrow, it'll have to wait until next year or you'll have to find other people with licences to verify this target change.

[AkhilTThomas]

In the absence of the Rust Project being able to build these targets in CI, I think it's important that the maintainers can at least verify that the target builds OK, and currently I cannot.

Totally agree.
I had hoped to tackle the issue of __my_thread_exit at libc level. On deeper inspection i find that this special symbol is absent in nto80 (verified by comparing objdump of libc.a for nto71 and nto80).
Hence the fix would be to remove it's usage in backtrace.rs for nto80 targets.

@flba-eb Could you do this change ? Since i don't have push access here.

[flba-eb]

In the absence of the Rust Project being able to build these targets in CI, I think it's important that the maintainers can at least verify that the target builds OK, and currently I cannot.

Totally agree. I had hoped to tackle the issue of __my_thread_exit at libc level. On deeper inspection i find that this special symbol is absent in nto80 (verified by comparing objdump of libc.a for nto71 and nto80). Hence the fix would be to remove it's usage in backtrace.rs for nto80 targets.

@flba-eb Could you do this change ? Since i don't have push access here.

Please note that so far, QNX targets have always been added even if they were only no_std with panic = "abort". It is the logical (and required) step before other work can be done, like adding support to libc, cc, ctest2. Afterwards we can add support to backtrace and libstd. Currently, we only support libstd on QNX 7.1 but neither 7.0 nor 8.0. See nto-qnx.md. Most crate maintainers reject pull requests when they are using targets that are not yet supported by the compiler, i.e. we have to add the target configuration first.

My proposal:

• Lets get this PR merged. It is okay that libstd and unwinding do not work yet.
• Lets discuss the "quality assurance" done by QNX maintainers separately and document it in nto-qnx.md. It should be clear from the document what users can expect from us.

[jonathanpallant]

ok, that makes sense - and it matches your table:

QNX Neutrino Version	Target Architecture	Full support	no_std support
8.0	AArch64	?	✓
8.0	x86	?	✓
7.1 with io-pkt	AArch64	✓	✓
7.1 with io-sock	AArch64	?	✓
7.1 with io-pkt	x86_64	✓	✓
7.1 with io-sock	x86_64	?	✓
7.0	AArch64	?	✓
7.0	x86		✓

For the benefit of anyone who didn't scroll to the bottom of the comments or read the changes to the platform docs, could we edit the PR description to explain which of the four new targets being added has working libstd support, and for those that targets that don't, the follow up steps that are required to enable such support?

[flba-eb]

After discussing this with @thejpster and @AkhilTThomas, we came to the conclusion that from our point of view this change can be merged.