Open brevilo opened 2 months ago
FYI: the CPU architecture reported by /proc/cpuinfo
does not indicate the actual architecture, according to this LKML thread. IOW, the 8
above does not refer to ARMv8 and should thus rather be ignored.
To make things even worse, we're seeing S24 devices which clearly have ARMv9.2-A cores in them, yet do not support their full instruction set. Looking at the CPU features reveals that they are effectively crippled down to armv8.6-a
in case of the S24 Ultra. Interestingly enough BOINC reports ABI: arm64-v8a
in host.product_name
, which is closer to the truth but not that helpful (there).
Another related observation: I rebuilt the binary for ARMv8-A since this is the first ISA with AArch64 support and should thus be the lowest common denominator to fix (well, work around) the mess from my previous comment. However, while I could execute the binary on my ARMv8 test device (BOINC 8.0.3, Android 11, AArch64 kernel) directly in an adb shell
, it immediately errored out under BOINC's anonymous platform (GitHub wiki entry is broken) with an execv: Exec format error
. Back to square one. This doesn't make sense. Even if BOINC would run a AArch32 client for some reason, it should still be able to execv
a AArch64 app, no? 🤷♂
Can someone confirm that anonymous platform is fully supported by BOINC on Android? Just to exclude the error above being a red herring...
Describe the bug This seems to indicate that BOINC falls back to
arm-android-linux-gnu
(aarch32
) if a project doesn't supportaarch64-android-linux-gnu
. Is that correct and always the case? If so, it shouldn't be since as of ARMv9-Aaarch32
support is optional and not implemented on the Cortex-A520, for instance.Steps To Reproduce
arm-android-linux-gnu
only)aarch32
appexec format error (8)
Expected behavior BOINC should not fall back to
aarch32
on Cortex-A520System Information
Additional context
[Impl 0x41 Arch8 Variant 0x0 Paart 0xd80 Rev 1]
(also notice the unrelated 'Paart' typo) which doesn't indicate that it's in fact architecture 9. Use a static list of part IDs that don't supportaarch32
anymore also seems error prone. Maybe simply drop the fallback?