Re: valgrind support for glibc/kernel arm64 HWCAPS

[Mark Wielaard <mark at klomp dot org>]

Hi,

Adding valgrind-developers (and dropping fedora glibc).

On Fri, 2017-06-23 at 17:40 +0530, Siddhesh Poyarekar wrote:
> 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.

The issue really is that I don't know what the HWCAP bits stand for. So
for me the only way is the conservative way assuming that since things
worked without any bits set, that is what we should default to for now.

Hopefully someone knows which instruction sets the HWCAPS bits stand for
and which ones are currently (fully) implemented in valgrind. Then we
can more selectively enable bits.

> 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?

Yes. IMHO.

>   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.

I am not sure I understand this part.
What are micro-architecture specific routines?

>   So once support for midr_el1 is in place, maybe
> hwcap_cpuid should be brought back.  Likewise for other flags.

Yes.

Cheers,

Mark