Re: valgrind support for glibc/kernel arm64 HWCAPS

[Mark Wielaard <mark at klomp dot org>]

On Thu, 2017-07-06 at 08:18 +0200, Florian Weimer wrote:
> On 07/06/2017 06:14 AM, Siddhesh Poyarekar wrote:
> > On Thursday 06 July 2017 12:34 AM, Florian Weimer wrote:
> >> Why do you expect valgrind to be able to execute code specific to vendor
> >> CPUs?  That's not even true for i386 and x86-64 and micro-architecture
> >> ISA extensions.
> > 
> > The expectation is that it looks for potential memory access issues in
> > these low level functions themselves, but that is probably too much to
> > expect.  However this:
> > 
> >    (c) the glibc SSE-variants can read past the end of the input data
> >        ranges. This can cause false-positive Memcheck / Helgrind / DRD
> >        reports.
> > 
> > sounds scary.  It's been a while since I've looked at the x86 versions
> > of the string functions, do you (or Mark) know what this is referring to
> > and why it is safe?
> 
> There is a page boundary check upfront, or this only happens after the
> pointer is aligned and the load cannot cross a page boundary.
> 
> > It would be nice to get some more details of this one as well:
> > 
> >    (b) some of the normal versions are hyper-optimised, which fools
> >        Memcheck and cause spurious value warnings.  Our versions are
> >        simpler.
> > 
> > specifically whether it is x86-specific or true for other architectures
> > as well
> 
> I'm not sure if this is what (b) is about, but for some instructions or
> instruction sequences it is hard to implement proper uninitialized value
> tracking, so that valgrind reports a dependency on uninitialized data
> which does not in fact exist because the bits are masked away in
> practice, but valgrind does not see this due to this problem.

Right, the hand-written glibc mem/str assembly routines are sometimes a
little too clever. valgrind/memcheck is optimized for code generated by
actual compilers. And valgrind has a somewhat stricter definition/view
of addressable memory (since it knows exactly how big an allocated
buffer is because it intercepts all memory allocation functions). See
also the valgrind/memcheck options --partial-loads-ok and
--expensive-definedness-checks:
http://valgrind.org/docs/manual/mc-manual.html#opt.partial-loads-ok
http://valgrind.org/docs/manual/mc-manual.html#opt.expensive-definedness-checks

In newer valgrind releases the first defaults to yes, the second to no.

Cheers,

Mark