This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: valgrind support for glibc master
On Friday 23 June 2017 05:10 PM, Mark Wielaard wrote:
> On Fri, 2017-06-23 at 16:47 +0530, Siddhesh Poyarekar wrote:
>> On Friday 23 June 2017 04:43 PM, Florian Weimer wrote:
>>> valgrind needs to mask out all unknown/unimplemented flags. And I
>>> thought it was 1? LD_HWCAP_MASK=1 acts as a workaround, after all.
>>
>> The remaining flags shouldn't actually matter to glibc since they're
>> essentially assumed features (asimd, fp) but there may be programs out
>> there that might read them.
>
> I found the following arm HWCAP bits in the kernel:
>
> #define HWCAP_FP (1 << 0)
> #define HWCAP_ASIMD (1 << 1)
> #define HWCAP_EVTSTRM (1 << 2)
> #define HWCAP_AES (1 << 3)
> #define HWCAP_PMULL (1 << 4)
> #define HWCAP_SHA1 (1 << 5)
> #define HWCAP_SHA2 (1 << 6)
> #define HWCAP_CRC32 (1 << 7)
> #define HWCAP_ATOMICS (1 << 8)
> #define HWCAP_FPHP (1 << 9)
> #define HWCAP_ASIMDHP (1 << 10)
> #define HWCAP_CPUID (1 << 11)
> #define HWCAP_ASIMDRDM (1 << 12)
> #define HWCAP_JSCVT (1 << 13)
> #define HWCAP_FCMA (1 << 14)
> #define HWCAP_LRCPC (1 << 15)
>
> BTW the glibc linux/aarch64/bitshwcap.h only go up to HWCAP_ASIMDRDM.
>
> Is there are corresponding ARM abi document that maps those values to
> the corresponding arm64 cpu instruction sets? Valgrind supports some,
> but certainly not all. Since valgrind emulates/translates all
> instructions explicitly it makes sense to mask off anything unknown.
Yeah I assumed that anything before CPUID was probably implemented in
valgrind already, but if that's the conservative way to go then so be it.
So does this mean that if there are specific hwcaps we know are
implemented in valgrind (now or in future), that the flags should be
enabled one by one? For example, if valgrind disables hwcap_cpuid then
bugs in micro-architecture specific routines may get masked out since
they will never get called (unless you're using the not-merged-yet
glibc.tune.cpu tunable) and it would change program behaviour
considerably. So once support for midr_el1 is in place, maybe
hwcap_cpuid should be brought back. Likewise for other flags.
Siddhesh