On Tue Jun 30 04:35:42 2026 +0000, Brendan Shanks wrote:
Thanks for the quick review, all good points. I've added `HWCAP_AES` and `HWCAP_CRC32` for aarch64. I hadn't realized there were 2 files with the `HWCAP_` defines, it makes sense to stick with just `sys/auxv.h` which we were already including anyway. `asm/hwcap.h` comes from the kernel headers whereas `sys/auxv.h` and `bits/hwcap.h` come from the C library. The redefinition warnings would be annoying, but it seems like the `4096` vs `(1 << 12)` mismatch was just with ARM and not AArch64? I took a look at the kernel AArch64 `asm/hwcap.h`, FreeBSD's `elf.h`, and `bits/hwcap.h` from glibc and musl and they're all consistent. There's always the potential for a mismatch in the future, but as long as everyone stays consistent it seems like there shouldn't be. Maybe we could resolve this in the future on the slim chance it becomes an issue? Sounds reasonable yes, to not bother with it, as it is consistent and nice all across aarch64.
This update broke building for ARM32 though. We're using the constants `HWCAP_NEON` etc - but `bits/hwcap.h` on glibc only defines `HWCAP_ARM_NEON`, while `asm/hwcap.h` which we now no longer include defined `HWCAP_NEON`. I had a look around, and FreeBSD's `elf.h` defines `#define HWCAP_NEON 0x00001000`, glibc's `bits/hwcap.h` defines `#define HWCAP_ARM_NEON 4096`, musl's `bits/hwcap.h` defines both `#define HWCAP_NEON (1 << 12)` and `#define HWCAP_ARM_NEON (1 << 12)`. So for these, I would suggest either: - Go with glibc's naming and provide an unconditional define of our own (`#define HWCAP_ARM_NEON 4096`) - at least within the quick check of glibc/musl/freebsd, there's only one defining it, and with that value, so we should be free of conflicts. - Go with the freebsd/kernel naming, and define it with an `#ifndef`. There are only three of these constants that we use, so it's not that much of a pain to do. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11267#note_144525