
* Manually preserve rbx across cpuid instruction This fixes an issue observed when using __cpuid and __cpuid_count with Address Sanitizer enabled: the generated code uses the rbx register to access ASAN tracking information without reloading it after cpuid, resulting in a segfault since the rbx register is overwritten by cpuid (https://crbug.com/1072045). This seems like a compiler backend bug, and indeed there is a long-standing LLVM bug report about a very similar issue: https://bugs.llvm.org/show_bug.cgi?id=17907 To work around this issue, we can manually preserve the rbx register contents in the inline assembly. This is the approach taken by LLVM's own host cpuid detection code (lib/Host/Support.cpp). The original rbx value is stashed in rsi, which is then swapped with rbx to restore the original value as well as keep the output ebx value from the CPUID instruction to be used as an output of the inline assembly. The rbx clobber is also removed; this seems ineffective, and it conflicts with the ebx output of the inline assembly (ebx is a subregister of rbx): "Note that clobbering named registers that are also present in output constraints is not legal." (https://llvm.org/docs/LangRef.html#clobber-constraints) * Add link to LLVM bug in cpuid workaround comment
core::arch
- Rust's core library architecture-specific intrinsics
The core::arch
module implements architecture-dependent intrinsics (e.g. SIMD).
Usage
core::arch
is available as part of libcore
and it is re-exported by
libstd
. Prefer using it via core::arch
or std::arch
than via this crate.
Unstable features are often available in nightly Rust via the
feature(stdsimd)
.
Using core::arch
via this crate requires nightly Rust, and it can (and does)
break often. The only cases in which you should consider using it via this crate
are:
-
if you need to re-compile
core::arch
yourself, e.g., with particular target-features enabled that are not enabled forlibcore
/libstd
. Note: if you need to re-compile it for a non-standard target, please prefer usingxargo
and re-compilinglibcore
/libstd
as appropriate instead of using this crate. -
using some features that might not be available even behind unstable Rust features. We try to keep these to a minimum. If you need to use some of these features, please open an issue so that we can expose them in nightly Rust and you can use them from there.
Documentation
- Documentation - i686
- Documentation - x86_64
- Documentation - arm
- Documentation - aarch64
- Documentation - powerpc
- Documentation - powerpc64
- How to get started
- How to help implement intrinsics
License
core_arch
is primarily distributed under the terms of both the MIT license and
the Apache License (Version 2.0), with portions covered by various BSD-like
licenses.
See LICENSE-APACHE, and LICENSE-MIT for details.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in core_arch
by you, as defined in the Apache-2.0 license,
shall be dual licensed as above, without any additional terms or conditions.