Bug 235994

Summary: devel/cpu_features: list_cpu_features program is broken
Product: Ports & Packages Reporter: John F. Carr <jfc>
Component: Individual Port(s)Assignee: Steven Kreuzer <skreuzer>
Status: New ---    
Severity: Affects Only Me CC: diizzy, mikael
Priority: --- Flags: bugzilla: maintainer-feedback? (skreuzer)
Version: Latest   
Hardware: arm64   
OS: Any   
Attachments:
Description Flags
patch none

Description John F. Carr 2019-02-24 12:54:31 UTC 
$ /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.
Comment 1 Steven Kreuzer freebsd_committer freebsd_triage 2019-03-09 01:02:32 UTC 
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
Comment 2 John F. Carr 2019-03-09 01:26:17 UTC 
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.
Comment 3 John F. Carr 2019-03-09 14:01:22 UTC 
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.
Comment 4 commit-hook freebsd_committer freebsd_triage 2019-03-18 01:36:20 UTC 
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
Comment 5 Mikael Urankar freebsd_committer freebsd_triage 2019-03-18 11:25:20 UTC 
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
Comment 6 Daniel Engberg freebsd_committer freebsd_triage 2021-09-15 21:44:11 UTC 
Any updates?
Comment 7 Steven Kreuzer freebsd_committer freebsd_triage 2021-09-16 20:04:44 UTC 
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?
Comment 8 Mikael Urankar freebsd_committer freebsd_triage 2021-09-17 18:28:59 UTC 
(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.