Expose is_x86_feature_detected to libcore

[g2p]

(not sure if this is the correct issue tracker)

This would be useful for Nebulet, which compiles as no_std.

[gnzlbg]

This is the correct issue tracker. Since is_x86_feature_detected requires operating-system support it cannot be provided in libcore.

core::arch provides you with the pieces required to build a run-time feature detection systems, so you could use that to build one that Nebulet can use, for example, based on the one provided by std.

You could provide it as an independent crate, so that others can use it. Just keep in mind that not all #[no_std] crates end up running on ring 0.

[g2p]

I did not realize the feature needed extra support, thank you for the informative reply.
At the moment I'm using https://github.com/gz/rust-cpuid to check for features in a no_std context.

[gnzlbg]

Appears to be similar to cupid in that it maps directly to the cpuid instruction.

Just keep in mind that a cpuid bit being set does not always imply that a feature can be used correctly (that is, without invoking undefined behavior). For some features like some of the SIMD related ones whether a feature can be used correctly will also depend on whether OS support is required, and if that's the case, on whether it is properly enabled.

[RReverser]

I'm currently using code like

if cfg!(feature = "use_std") {
  is_x86_feature_detected!("sse4.2")
} else {
  cfg!(target_feature = "sse4.2")
}

to work around this. I wonder if it would make sense for core to provide a fallback version of is_x86_feature_detected! that would do at least the second part (transparently falling back to at least compile-time target feature flag).

[gnzlbg]

I wonder if it would make sense for core to provide a fallback version of is_x86_feature_detected! that would do at least the second part (transparently falling back to at least compile-time target feature flag).

We actually want to be able to use full run-time feature detection from core (including being able to use the libstd system from core if libstd ends up linked in the final binary), but it is unclear right now how to do it. RFC2492 might be what we need, I've left a comment about this there yesterday (rust-lang/rfcs#2492 (comment) ).

[gnzlbg]

@RReverser in the mean time, if you end up doing that a lot, it would make sense to just write your own macro to abstract it away.

[josephlr]

Since is_x86_feature_detected requires operating-system support it cannot be provided in libcore.

@gnzlbg I'm a bit confused by this. For x86, all features are detected via CPUID or via XCR0 (which requires the OS to enable osxsave), both of which are available in usersapce. This means that while OS support is needed to enable these features, no OS support is needed to detect these features. The detect_features function doesn't use anything that's not already in libcore. std_detect even notes that "On x86/x86_64 no OS specific functionality is required":

stdarch/crates/std_detect/src/detect/mod.rs

Line 97 in f1934fd

// On x86/x86_64 no OS specific functionality is required.

Both ring (see the linked issue) and getrandom (for the RDRAND implementation) have had to work around this by duplicating parts of std_detect's code in their own crates. This seems unnecessary.

I know the story for other arches is different, but it seems like nothing is preventing providing is_x86_feature_detected!() as part of libcore.