|
From: Mark W. <ma...@kl...> - 2017-07-05 15:43:05
|
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 |
|
From: Mark W. <ma...@kl...> - 2017-07-05 19:48:38
|
On Thu, 2017-07-06 at 00:26 +0530, Siddhesh Poyarekar wrote: > On Wednesday 05 July 2017 09:12 PM, Mark Wielaard wrote: > > I am not sure I understand this part. > > What are micro-architecture specific routines? > > These are routines written specifically for vendor CPUs, such as the > thunderx version of memcpy and memmove. The HWCAP_CPUID allows for such > routines to be launched on the correct hardware, but when run under > valgrind, those routines will not get called and any potential bugs in > those routines may get masked. aha. We probably already intercept such implementations of memcpy and memmove with our own versions anyway. See the shared/vg_replace_strmem.c source in valgrind for some of the reasons for intercepting these hyper optimized string/memory functions. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2017-07-06 07:26:41
|
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 |