$ /usr/local/bin/list_cpu_features Could not dlopen() C library: /usr/lib/libc.so: invalid file format Parsing /proc/self/auxv to extract ELF hwcaps! Could not open /proc/self/auxv Could not dlopen() C library: /usr/lib/libc.so: invalid file format Parsing /proc/self/auxv to extract ELF hwcaps! Could not open /proc/self/auxv arch : aarch64 implementer : 0 (0x00) variant : 0 (0x00) part : 0 (0x00) revision : 0 (0x00) flags : $ The errors at start tell me this program assumes it is running on Linux. On my system libc.so is a linker script instead of an ELF file and there is no /proc filesystem. The package also has a library. I did not test it.
What type of board are you trying to run this on and did you install it from ports or via pkg? Unfortunately, I don't have access to any ARM hosts at this time so this may be difficult to debug
uname -a reports: FreeBSD striatus 13.0-CURRENT FreeBSD 13.0-CURRENT r344398 GENERIC arm64 The machine is a Softiron Overdrive 1000. The processor is an Opteron A1100 quad core Cortex A-57. I built from source. It looks like HWCAPS_ANDROID_MIPS_OR_ARM is being defined (that protects the only mention of libc.so) based on the assumption that any ARM processor must be running Android. #if defined(CPU_FEATURES_ARCH_MIPS) || defined(CPU_FEATURES_ARCH_ANY_ARM) #define HWCAPS_ANDROID_MIPS_OR_ARM #endif If I comment out the definition of HWCAPS_ANDROID_MIPS_OR_ARM I don't get any more errors, but I get the same all zero output. I will explore the source more over the weekend.
The Linux code wants to call getauxval to get hardware capabilities. The equivalent function on FreeBSD is the undocumented function elf_aux_info. On my 64 bit ARM system elf_aux_info does not support hwcap. More specifically, unsigned long hwcap = ~0UL; int rv = elf_aux_info(AT_HWCAP2, &hwcap, sizeof hwcap); returns 2, ENOENT. According to lib/libc/gen/auxv.c that means the value was not passed to the program. So a kernel change would be required. It may be possible to use a sysctl interface instead. But then the program would have to be rewritten to use BSD-specific instead of Linux-specific bit values. In its current state the port should be disabled for 64 bit ARM. I suspect it should be disabled for 32 bit ARM too, but I'm only running 64 bit.
A commit references this bug: Author: skreuzer Date: Mon Mar 18 01:35:37 UTC 2019 New revision: 496118 URL: https://svnweb.freebsd.org/changeset/ports/496118 Log: Set NOT_FOR_ARCHS on arm and mips HWCAPS_ANDROID_MIPS_OR_ARM is being defined based on the assumption that any ARM processor must be running Android. PR: 235994 Reported by: John F. Carr <jfc@mit.edu> Changes: head/devel/cpu_features/Makefile
Created attachment 202953 [details] patch You can retrieve some cpu info with the attached patch: /usr/local/bin/list_cpu_features arch : aarch64 implementer : 0 (0x00) variant : 0 (0x00) part : 0 (0x00) revision : 0 (0x00) flags : asimd,crc32,fp,pmull,sha1,sha2 It's also possible to get the missing field (implementer, variant...) but it's a bit harder
Any updates?
I just updated the port to v0.6.0 and back ported a patch from upstream to support freebsd on x86. It has been implemented by reading /var/run/dmesg.boot and parsing out Features= and Features2= Do you have an example dmesg.boot from a arm host?
(In reply to Steven Kreuzer from comment #7) It's better to use elf_aux_info(3) on arm, /var/run/dmesg.boot may not exist.