bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH hurd] Add partial /proc/cpuinfo implementation


From: Jessica Clarke
Subject: Re: [RFC PATCH hurd] Add partial /proc/cpuinfo implementation
Date: Thu, 9 Jan 2025 15:18:38 +0000

On 9 Jan 2025, at 15:12, Diego Nieto Cid <dnietoc@gmail.com> wrote:
> 
> Hi,
> 
> On Thu, Jan 09, 2025 at 11:51:27AM +0300, Sergey Bugaev wrote:
>> 
>> "Implementer", "architecture", "variant", "part", "revision" come from
>> midr/revidr [0], and "features" are hwcap names. These are privileged
>> registers that only EL1 can read, but on AArch64 gnumach, their values
>> are obtainable from userland using the aarch64_get_hwcaps RPC (see
>> gnumach:aarch64/include/mach/aarch64/mach_aarch64.defs and
>> gnumach:aarch64/include/mach/aarch64/mach_aarch64_types.h).
> 
> Looking at the types.h header, I see there are HWCAP2_* definitions for
> bits above 32. Since hwcaps_t is an uint32_t and the defs file claims to
> return two values (I assume the first for HWCAP_* and the second for
> HWCAP2_*), I don't see how to get the higher bits of HWCAP2_*.
> 
> How does that work?

On Linux, FreeBSD and any other OS that implements AT_HWCAP(2), you get
hwcaps via auxv, and Elf_Auxinfo’s a_un.a_val is a long, so it’s 64-bit
on 64-bit architectures, which aarch64 is. Making hwcaps_t a uint32_t
on aarch64 is a mistake.

Jess




reply via email to

[Prev in Thread] Current Thread [Next in Thread]