-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use LLVM objdump on Macos instead of otool for CI tests #1208
Conversation
…TME support with otool
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) soon. Please see the contribution instructions for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks fine, trying to not duplicate the two similar codepaths probably is not worth it. I wonder if just unifying to use objdump on macos also on x86_64 wouldn't make the code simpler though.
Good idea! I added a commit to use objdump for x86_64 as well and it actually works better on a M1 Mac with Rosetta2 emulation than otool which just hangs. Can be squashed once approved. |
Objdump seems to work properly with Big Sur only (don't have an older Mac to test). ARM64 support came with Big Sur so that is not a problem, not sure if it is an issue for x86_64. |
If the one provided from llvm-tools-preview works, we could just suggest to use it. |
I like the set @Amanieu is it good for you as well? I guess it could land with the |
It works but exposes another bug in the testing framework, namely that we currently check the disassembled code for the string "call" to find non-inlined intrinsics (despite that not being the instruction for subroutine call on aarch64) and the disassembly crated from the new llvm-objdump contains relative addresses like this:
which thus causes incorrect test failures. |
You may squash the starts_with fixup with 0cb9065, then it would be good to go IMHO. Thank you a lot :) |
…M should be gone.
655fa1e
to
eca3bdd
Compare
Update stdarch submodule This is mainly to fix the critical issue of aarch64 store intrinsics overwriting additional memory, see rust-lang/stdarch#1220 Changes: * aarch64/armv7: additional vld1/vst1 intrinsics + perf fixes for existing ones * rust-lang/stdarch#1205 * rust-lang/stdarch#1207 * rust-lang/stdarch#1216 * armv7: Make FMA work with vfpv4 and optimize * rust-lang/stdarch#1219 * Non-visible changes to the testing framework * rust-lang/stdarch#1208 * rust-lang/stdarch#1211 * rust-lang/stdarch#1213 * rust-lang/stdarch#1215 * rust-lang/stdarch#1218
Enabling target features is not possible with otool. Setting a target CPU is possible but the Transactional Memory Extension (TME) is not supported by any CPU yet so that does not help. LLVM objdump is installed with the developer tools out of the box and can be used instead.
Edit: Now uses LLVM objdump for x86_64 as well.