On Wed, Jul 15, 2026 at 7:23 AM Michael Tokarev <[email protected]> wrote:
>
> On 7/13/26 04:36, Matt Turner wrote:
> > Alpha has never set AT_HWCAP in linux-user emulation, so getauxval(AT_HWCAP)
> > always returned 0 regardless of the emulated CPU model.
> >
> > The Linux kernel computes ELF_HWCAP as ~amask(-1), i.e. the set of ISA
> > extension bits that the amask instruction reports as supported (cleared in
> > its output).  env->amask stores exactly those bits with the same layout
> > (BWX=0x1, FIX=0x2, CIX=0x4, MVI=0x100, TRAP=0x200, PREFETCH=0x1000), so
> > returning it directly from get_elf_hwcap matches the kernel convention.
> >
> > Add HAVE_ELF_HWCAP to target_elf.h and implement get_elf_hwcap() in
> > elfload.c to expose the emulated CPU's capability mask to user-space
> > programs via the auxiliary vector.
> >
> > Without this fix, programs using getauxval(AT_HWCAP) to detect BWX/FIX/CIX
> > (such as glibc's memcpy or JIT compilers targeting Alpha) incorrectly
> > concluded that no extensions were available even when emulating ev56+.
>
> In stable 10.0.x qemu series, things are different from what we have
> now, - there, everything is in single linux-user/elfload.c and the
> context is a bit different too.
>
> Here's my backport of this change to 10.0.x:
> https://gitlab.com/mjt0k/qemu/-/commit/e4c1bf9b1fe030ef1d0d4c74086cccb62c6b0442
>
> I appreciate a quick look at the result, whenever it looks good for
> 10.0.x or not.

Looks good to me. Thank you!

Reply via email to