check before test for hardware capabilites in bits 32~63 of usize

[h3fang]

This commit tries to fix #146230.

std::arch::is_aarch64_feature_detected panics on aarch64 ILP32 targets.

After some digging, the real problem is

rust/library/std_detect/src/detect/os/linux/aarch64.rs

Lines 210 to 241 in 91edc3e

	// ebf16: bit::test(auxv.hwcap2, 32),
	// sveebf16: bit::test(auxv.hwcap2, 33),
	cssc: bit::test(auxv.hwcap2, 34),
	// rprfm: bit::test(auxv.hwcap2, 35),
	sve2p1: bit::test(auxv.hwcap2, 36),
	sme2: bit::test(auxv.hwcap2, 37),
	sme2p1: bit::test(auxv.hwcap2, 38),
	// smei16i32: bit::test(auxv.hwcap2, 39),
	// smebi32i32: bit::test(auxv.hwcap2, 40),
	smeb16b16: bit::test(auxv.hwcap2, 41),
	smef16f16: bit::test(auxv.hwcap2, 42),
	mops: bit::test(auxv.hwcap2, 43),
	hbc: bit::test(auxv.hwcap2, 44),
	sveb16b16: bit::test(auxv.hwcap2, 45),
	lrcpc3: bit::test(auxv.hwcap2, 46),
	lse128: bit::test(auxv.hwcap2, 47),
	fpmr: bit::test(auxv.hwcap2, 48),
	lut: bit::test(auxv.hwcap2, 49),
	faminmax: bit::test(auxv.hwcap2, 50),
	f8cvt: bit::test(auxv.hwcap2, 51),
	f8fma: bit::test(auxv.hwcap2, 52),
	f8dp4: bit::test(auxv.hwcap2, 53),
	f8dp2: bit::test(auxv.hwcap2, 54),
	f8e4m3: bit::test(auxv.hwcap2, 55),
	f8e5m2: bit::test(auxv.hwcap2, 56),
	smelutv2: bit::test(auxv.hwcap2, 57),
	smef8f16: bit::test(auxv.hwcap2, 58),
	smef8f32: bit::test(auxv.hwcap2, 59),
	smesf8fma: bit::test(auxv.hwcap2, 60),
	smesf8dp4: bit::test(auxv.hwcap2, 61),
	smesf8dp2: bit::test(auxv.hwcap2, 62),
	// pauthlr: bit::test(auxv.hwcap2, ??),

checks bits 32~63 of usize unconditionally on normal aarch64 LP64 target and aarch64 ILP32 target.

Here I propose to move these to a block guarded by #[cfg(target_pointer_width="64")].

See #146230 for more detailed analysis.

r? @Amanieu

[folkertdev]

Could you add a bit more to the PR description: a short summary of the problem, and of the solution.

Also, does this change actually fix the issue you're observing?

View changes since this review

[folkertdev]

This should at least get a comment, because I think it's quite reasonable to assume that aarch64 implies 64-bit pointers.

[folkertdev]

also now you're basically saying that the features in this block cannot be queried for on ilp32, is that correct?

[h3fang]

Ok, I will add some comment to clarify it.

[h3fang]

also now you're basically saying that the features in this block cannot be queried for on ilp32, is that correct?

Yes, the libc::getauxval returns 32 bit c_ulong for aarch64 ILP32 target.

[h3fang]

also now you're basically saying that the features in this block cannot be queried for on ilp32, is that correct?

Well, to be more accurate, they can be queried, but the values will all be false.

[h3fang]

This should at least get a comment, because I think it's quite reasonable to assume that aarch64 implies 64-bit pointers.

I have added some comments to clarify it.

[h3fang]

Could you add a bit more to the PR description: a short summary of the problem, and of the solution.

I have updated the PR description.

Also, does this change actually fix the issue you're observing?

It should. I will test it on the real hardware soon.

[h3fang]

Also, does this change actually fix the issue you're observing?

It should. I will test it on the real hardware soon.

Yes, it does fix the issue. I have verified that on the real hardware.

The following code ran and printed true without panic in debug build.

fn main() {
    println!("{:?}", std::arch::is_aarch64_feature_detected!("lse"));
}