valgrind support for glibc/kernel arm64 HWCAPS

Florian Weimer fweimer@redhat.com
Thu Jul 6 06:21:00 GMT 2017


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.

But this isn't what I meant.  There is an expectation that even after we
add SSE5-based IFUNCs to glibc, you can still use current valgrind to
run programs on SSE5-capable systems.

Thanks,
Florian



More information about the Libc-alpha mailing list