Add support for xray in aarch64 unknown none target #148666
Open
+1
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 thesupports_xray: trueoption inTargetOptionsforcompiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs.Using this toolchain in
rustupI 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-nonewould 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.rsfile usingcargo::rustc-link-lib=LIBif 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 foraarch64-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.