Fix build on FreeBSD/powerpc*

[kgotlinux]

All the tests pass.

[Mizux]

FYI x86 implem do support Linux(or Android) and FreeBSD but sources are splitted...

• src/impl_x86_freebsd.c
• src/impl_x86_linux_or_android.c

So do we keep the same file "layout" for PowerPC ? or rename the file impl_ppc_linux_or_freebsd.c
note: I don't remember why we split the sources
EDIT:

cpu_features/src/impl_x86_freebsd.c

Lines 33 to 34 in c74a85d

	// Handling FreeBSD platform through parsing /var/run/dmesg.boot.
	const int fd = CpuFeatures_OpenFile("/var/run/dmesg.boot");

cpu_features/src/impl_x86_linux_or_android.c

Lines 32 to 33 in c74a85d

	// Handling Linux platform through /proc/cpuinfo.
	const int fd = CpuFeatures_OpenFile("/proc/cpuinfo");

[gchatelet]

For FreeBSD we need to parse /var/run/dmesg.boot instead of /proc/cpuinfo and the format is not the same.
So it's definitely not the same way of detecting the features.
Tests "pass" because we create a fake filesystem with /proc/cpuinfo, but it won't exist on a real FreeBSD so this patch is incorrect.

[pkubaj]

While the current implementation with /proc/cpuinfo is wrong, parsing /var/run/dmesg.boot is also wrong even if it works. On FreeBSD you need to use elf_aux_info() to get CPU capabilities. It works similarly to Linux's getauxval().

[gchatelet]

While the current implementation with /proc/cpuinfo is wrong, parsing /var/run/dmesg.boot is also wrong even if it works. On FreeBSD you need to use elf_aux_info() to get CPU capabilities. It works similarly to Linuxs getauxval()`.

Ah! Thx a lot for the information. I was unaware of elf_aux_info().
We'll look into this. @pkubaj do you know if the function is always available or if it needs dynamic loading as for android?

[pkubaj]

This function is available without dynamic loading. You just need FreeBSD 12.0 or newer and include sys/auxv.h. An example of using it would be https://github.com/zlib-ng/zlib-ng/pull/1340/files

[kgotlinux]

Pull request rebased and fixed, It currently builds on the support added in 89a3f03, which adds support for using elf_aux_info() on FreeBSD. Currently list_cpu_features correctly lists architecture and CPU features, It does not list CPU model, microarchitecture etc., due to no AT_PLATFORM on FreeBSD.

[toor1245]

@kgotlinux, could you please add src/impl_ppc_freebsd.c file to BUILD.bazel: https://github.com/google/cpu_features/blob/main/BUILD.bazel#L237
https://github.com/google/cpu_features/blob/main/BUILD.bazel#L302

and make sure the following command will work fine?

bazel run list_cpu_features 

[gchatelet]

@kgotlinux can you clang format the c file?

EDIT: never mind, I'll do it.

[toor1245]

@gchatelet, I see bug and compilation error labels, but we didn't have support FreeBSD powerpc at all, so I would say this is new architecture support for FreeBSD.

[gchatelet]

@gchatelet, I see bug and compilation error labels, but we didn't have support FreeBSD powerpc at all, so I would say this is new architecture support for FreeBSD.

Fair enough, thx for noticing.
Let's try to add CI support for this patch before merging.

@Mizux would you have a bit of time to add CI for FreeBSD / Power ?

[brad0]

For FreeBSD we need to parse /var/run/dmesg.boot instead of /proc/cpuinfo and the format is not the same. So it's definitely not the same way of detecting the features. Tests "pass" because we create a fake filesystem with /proc/cpuinfo, but it won't exist on a real FreeBSD so this patch is incorrect.

@gchatelet And I question why cpu_features does something so bizarre on X86 when nothing else in the ecosystem of OSS does?

[brad0]

I bumped into this PR when wanting to add support for OpenBSD/powerpc and powerpc64. No point reinventing the wheel when this looks close enough to what I was looking for.