Add support for xray in aarch64 unknown none targets by odlot · Pull Request #148666 · rust-lang/rust

odlot · 2025-11-07T19:28:53Z

I am currently working on an embedded project and use the target aarch64-unknown-none, which I want to profile.
I found the following compiler flag -Z instrument-xray (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the supports_xray: true option in TargetOptions for compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs.
Using this toolchain in rustup I am able to use the instrumentation pass and I verified that the disassembly looks as what I want.
I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for aarch64-unknown-none.
I argue that someone who cross-compiles for aarch64-unknown-none would be okay with writing a separate runtime library themselves, which I intend to do.
As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their build.rs file using cargo::rustc-link-lib=LIB if there is an XRay LIB available for the respective target, e.g., clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a (which afaik there isn't for aarch64-unknown-none) and do "configuration as code" of XRay's options.
It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library.

I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.

rustbot · 2025-11-07T19:28:57Z

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

rustbot · 2025-11-07T19:28:59Z

r? @wesleywiser

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

odlot · 2025-11-30T19:57:06Z

@wesleywiser were you able to take a look yet? As far as I can tell CI failed because CI was in general broken at that point in time, I unfortunately can not rerun the pipeline.

bors · 2025-12-03T13:18:23Z

☔ The latest upstream changes (presumably #149581) made this pull request unmergeable. Please resolve the merge conflicts.

odlot · 2026-01-20T20:24:55Z

Anything from my side to do here?

wesleywiser

The rationale provided makes sense to me but as far as I'm aware, there are no other targets that "support" xray in this way. I think it potentially makes sense to do this for the other *-none targets as well.

@davidtwco what do you think?

View changes since this review

odlot · 2026-04-26T07:19:31Z

Good point, I can also add this option to the aarch64-unknown-none-softfloat because we moved from aarch64-unknown-none and these are the two targets I've actually implemented and tested an analysis pass for.

davidtwco · 2026-04-28T12:10:38Z

I think I'm fine with this - it makes sense that we'd allow use of -Zinstrument-xray on targets that do support it, even if that requires a little bit more work, it's still something you need to opt-in to so it won't affect anyone accidentally. We should adjust the docs to clarify that -Zinstrument-xray might require you do a bit more work.

wesleywiser

@odlot thanks for your patience! If you wouldn't mind adding a mention of this to the docs in src/doc/unstable-book/src/compiler-flags/instrument-xray.md that would be awesome. Happy to approve after that!

View changes since this review

rustbot · 2026-05-07T21:39:19Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rustbot · 2026-05-11T19:37:30Z

This PR was rebased onto a different main 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.

odlot · 2026-05-12T04:07:35Z

@rustbot ready

wesleywiser · 2026-05-19T08:16:34Z

@bors r+ rollup

rust-bors · 2026-05-19T08:16:37Z

📌 Commit 743c6a6 has been approved by wesleywiser

It is now in the queue for this repository.

Add support for xray in aarch64 unknown none targets I am currently working on an embedded project and use the target `aarch64-unknown-none`, which I want to profile. I found the following compiler flag `-Z instrument-xray` (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the `supports_xray: true` option in `TargetOptions` for `compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs`. Using this toolchain in `rustup` I am able to use the instrumentation pass and I verified that the disassembly looks as what I want. I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for `aarch64-unknown-none`. I argue that someone who cross-compiles for `aarch64-unknown-none` would be okay with writing a separate runtime library themselves, which I intend to do. As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their `build.rs` file using `cargo::rustc-link-lib=LIB` if there is an XRay LIB available for the respective target, e.g., `clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a` (which afaik there isn't for `aarch64-unknown-none`) and do "configuration as code" of XRay's options. It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library. I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.

rust-bors · 2026-05-19T09:21:44Z

💔 Test for 990826b failed: CI. Failed job:

auto - dist-powerpc64le-linux-musl (web logs, enhanced plaintext logs)

rust-log-analyzer · 2026-05-19T09:37:23Z

A job failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

JonathanBrouwer · 2026-05-19T09:57:36Z

@bors retry

…uwer Rollup of 6 pull requests Successful merges: - #154265 (ci: Add dist-aarch64-freebsd) - #156739 (miri subtree update) - #148666 (Add support for xray in aarch64 unknown none targets) - #156547 (Move tests closures) - #156578 (Add FileCheck for build_correct_coerce) - #156734 ([rustdoc] Move `span_map` file to the right folder)

Rollup merge of #148666 - odlot:master, r=wesleywiser Add support for xray in aarch64 unknown none targets I am currently working on an embedded project and use the target `aarch64-unknown-none`, which I want to profile. I found the following compiler flag `-Z instrument-xray` (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the `supports_xray: true` option in `TargetOptions` for `compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs`. Using this toolchain in `rustup` I am able to use the instrumentation pass and I verified that the disassembly looks as what I want. I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for `aarch64-unknown-none`. I argue that someone who cross-compiles for `aarch64-unknown-none` would be okay with writing a separate runtime library themselves, which I intend to do. As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their `build.rs` file using `cargo::rustc-link-lib=LIB` if there is an XRay LIB available for the respective target, e.g., `clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a` (which afaik there isn't for `aarch64-unknown-none`) and do "configuration as code" of XRay's options. It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library. I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.

…uwer Rollup of 6 pull requests Successful merges: - rust-lang/rust#154265 (ci: Add dist-aarch64-freebsd) - rust-lang/rust#156739 (miri subtree update) - rust-lang/rust#148666 (Add support for xray in aarch64 unknown none targets) - rust-lang/rust#156547 (Move tests closures) - rust-lang/rust#156578 (Add FileCheck for build_correct_coerce) - rust-lang/rust#156734 ([rustdoc] Move `span_map` file to the right folder)

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 7, 2025

rustbot assigned wesleywiser Nov 7, 2025

This comment has been minimized.
Sign in to view

rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 4, 2025

odlot closed this Dec 4, 2025

odlot force-pushed the master branch from 8b9e8b2 to 29e035eCompare December 4, 2025 20:11

odlot reopened this Dec 4, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 4, 2025

wesleywiser approved these changes Apr 23, 2026
View reviewed changes

wesleywiser requested changes May 7, 2026
View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 7, 2026

This comment has been minimized.
Sign in to view

rustbot added the has-merge-commits PR has merge commits, merge with caution. label May 11, 2026

rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 11, 2026

Add support for xray in aarch64 unknown none softfloat target
689279e

odlot changed the title ~~Add support for xray in aarch64 unknown none target~~Add support for xray in aarch64 unknown none targetsMay 11, 2026

docs: Add remark to bring your own runtime if none available
743c6a6

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 12, 2026

wesleywiser approved these changes May 19, 2026
View reviewed changes

rust-borsBot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 19, 2026

This comment has been minimized.
Sign in to view

rust-borsBot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 19, 2026

rust-borsBot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 19, 2026

JonathanBrouwer mentioned this pull request May 19, 2026
Rollup of 6 pull requests #156751
Merged

rust-borsBot merged commit 93e516b into rust-lang:mainMay 19, 2026
11 of 12 checks passed

rustbot added this to the 1.97.0 milestone May 19, 2026

Uh oh!

Uh oh!

Conversation

odlot commented Nov 7, 2025• edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Nov 7, 2025

Uh oh!

rustbot commented Nov 7, 2025

Uh oh!

This comment has been minimized.

odlot commented Nov 30, 2025

Uh oh!

bors commented Dec 3, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

odlot commented Jan 20, 2026

Uh oh!

wesleywiser left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odlot commented Apr 26, 2026

Uh oh!

davidtwco commented Apr 28, 2026

Uh oh!

wesleywiser left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented May 7, 2026

Uh oh!

rustbot commented May 11, 2026

Uh oh!

This comment has been minimized.

odlot commented May 12, 2026

Uh oh!

wesleywiser commented May 19, 2026

Uh oh!

rust-borsBot commented May 19, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented May 19, 2026

Uh oh!

rust-log-analyzer commented May 19, 2026

Uh oh!

JonathanBrouwer commented May 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

odlot commented Nov 7, 2025•
edited by rustbot
Loading

wesleywiser left a comment •
edited by rustbot
Loading

wesleywiser left a comment •
edited by rustbot
Loading