March and valgrind

Development
1

I’ve been recompiling my system with native binaries because I was going to setup a binary cache soon, and I found a major problem I have is Valgrind checks. Now I know for each package you can set overlays and such to avoid this, but there should be safe guards within nixpkgs itself to check if the system is being rebuild with a unsupported Valgrind cpu. Since Valgrind itself has stated that it will not support sse4 or avx.

  • X86/Linux: up to and including SSSE3, but not higher – no SSE4, AVX, AVX2. This target is in maintenance mode now…
  • AMD64/Linux: up to and including AVX2. This is the primary development target and tends to be well supported.
    Valgrind: Supported Platforms

I wanted to ask what everyone else thinks about this. I’m not sure how I would write a patch for this yet.

Discussion started here

2

The way I read the citation, this holds for 32-bit but 64-bit supports including avx2, i.e. pretty modern stuff.

3

Not at all, AVX2 is from 2013 and SSE4 is from 2008, we already know exactly what features the cpu is building for.

4

Yes, well, whatever. It’s subjective. To me AVX2 is a pretty modern thing to set as a lower bound, but no point in discussing. (I just perfectly understand that valgrind doesn’t bother with supporting emulation beyond AVX2.)

So sure, patch tests or disable them, what else. Doing special things (like you attempt now) often requires extra work :person_shrugging:

5

Echoing vcunat:

I find that many packages’ checkPhase will nondeterminstically fail when you enable the extra instruction sets. I have several places in my config devoted to this. The easiest thing to do is to disable the checkPhase most of the time. It’s tricky to reproduce the failure sometimes and typically the error needs to be reported upstream. My understanding is this isn’t a nixpkgs problem – the upstream package’s tests aren’t tested with the extra instruction sets

6

If this was nondeterminstically I would agree, but it isn’t. Valgrind states they will not support this. This is just gonna become more of a problem the more special instructions are added, this will just become worse overtime.

7

In the particular case of valgrind specifically, you can add line about it being broken to the derivation. E.g. something like:

broken =  with stdenv.targetPlatform; if (system == "x86_64-linux") && (  sse4_1Support || sse4_2Support || sse4_aSupport);

You could also maybe combine with a check for stdenv.targetPlatform.gcc.arch or stdenv.targetPlatform.gcc.tune. I feel suspect these checks might be painful to maintain since AFAIU very few people use these settings in the first place (source: couldn’t find much on sourcegraph about mtune/march being set when I looked a few months ago). So, not many developers will be testing this setup.

8

Broken seems harsh, because its often just the checks failing, not the package. I was thinking of the ladder idea. Since Valgrind has layed out hard limits for their support we can just skip if the system has any features that aren’t supported or blankly, above x86_64 v2. Do you know where these checks are for valgrind? I couldn’t find anything in the stdenv but this is my first time looking at the inner code.