Closed rprichard closed 5 days ago
The https://github.com/pytorch/cpuinfo project also detects the Krait idiv non-kernel-reporting bug, but it matches any CPU where the implementer is 'Q'/0x51 and the CPU part is 0x04d or 0x06f. It ignores the other MIDR fields (variant, architecture, and revision). The Android cpu-features.c code only ignores the "architecture" field, because it ignores the CPU architecture
field in /proc/cpuinfo
.
If Android cpu-features's Krait workaround also ignored variant and revision, then it too would recognize my Nexus 7 device as supporting idiv.
pytorch cpuinfo references:
implementer
and part
come from /proc/cpuinfo, and 'Q' is 0x51 in ASCII.lol, i'm really torn on this ... on the one hand "deprecated; we're actively telling people to move to the google cpufeatures", but on the other "breaks our own tests on our own devices" ...
Ah, I didn't realize it was deprecated. From https://developer.android.com/ndk/guides/cpu-features:
The NDK still provides a deprecated library named cpufeatures for source compatibility with apps that already use it. Unlike the newer and more complete cpu_features library, this historical library does not have workarounds for about specific SoCs.
I don't think I understand that last sentence, "does not have workarounds for about specific SoCs". Should it be "for as many specific SoCs"?
It looks like google/cpu_features uses the same logic as the NDK's cpufeatures, so it would similarly report the 2013 Nexus 7 CPU as lacking idiv: https://github.com/google/cpu_features/blob/ebcdfcaeffe67607d112ce019a12ad1c73e0475e/src/impl_arm_linux_or_android.c#L155-L160
Both google/cpu_features and cpufeatures have code using dlopen/dlsym to get getauxval. e.g. In cpu_features:
#if defined(HAVE_STRONG_GETAUXVAL)
#include <sys/auxv.h>
static unsigned long GetElfHwcapFromGetauxval(uint32_t hwcap_type) {
return getauxval(hwcap_type);
}
#elif defined(HAVE_DLFCN_H)
// On Android we probe the system's C library for a 'getauxval' function and
// call it if it exits, or return 0 for failure. This function is available
// since API level 20.
//
// This code does *NOT* check for '__ANDROID_API__ >= 20' to support the edge
// case where some NDK developers use headers for a platform that is newer than
// the one really targetted by their application. This is typically done to use
// newer native APIs only when running on more recent Android versions, and
// requires careful symbol management.
//
// Note that getauxval() can't really be re-implemented here, because its
// implementation does not parse /proc/self/auxv. Instead it depends on values
// that are passed by the kernel at process-init time to the C runtime
// initialization layer.
... use dlopen and dlsym ...
The NDK stubs and sys/auxv.h report that getauxval is available starting with API 18. Also, I think the CMake file will respect __ANDROID_API__
:
check_symbol_exists(getauxval "sys/auxv.h" HAVE_STRONG_GETAUXVAL)
(I'm not sure exactly what kind of check that check_symbol_exists
will do, but I think it will report getauxval as available/unavailable depending on __ANDROID_API__
.)
The upstream kernel also has a version of this Krait idiv workaround:
The kernel patches come from CodeAurora.
It looks like it recognizes a large range of part numbers as Krait -- [0x040..0x07f] inclusive.
It looks like the MIDR architecture field for Krait is 0xf (not, say, 7). I think that matches the scheme documented here: https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/CP15-registers-for-a-VMSA-implementation/c0--Main-ID-Register--MIDR-
I don't think I understand that last sentence, "does not have workarounds for about specific SoCs". Should it be "for as many specific SoCs"?
yeah, fixed: https://critique-ng.corp.google.com/cl/410265000
anyway, yeah, please send a fix/file a bug with the "real" cpu_features, and, yeah, even if this is deprecated, it makes sense to add this historical workaround since it's affecting our testing.
i also wonder whether we should actually add the deprecated annotations to the header? is the "real" cpu_features in prefab yet? (we should probably make it easy to do the new right thing before we make it more annoying to keep using the easy but deprecated thing. https://goomics.net/50/ )
This is now causing CI test failures with armeabi-v7a-19-new.
Closing since this library is no longer maintained.
(and i just checked that we already fixed the part of the documentation that caused confusion above.)
The
udiv
andsdiv
instructions seem to work on this device, in both ARM and Thumb modes. android_getCpuFeatures() isn't reporting either of ANDROID_CPU_ARM_FEATURE_IDIV_ARM or ANDROID_CPU_ARM_FEATURE_IDIV_THUMB2./proc/cpuinfo doesn't report any of idiv, idiva, or idivt.
The build fingerprint is google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys.
/proc/cpuinfo:
fastboot reports:
cpu-features.c already has code to work around a lack of idiv reporting. Maybe this device is similar?
The chipsets for the Nexus 4 and the 2013 Nexus 7 devices look similar: