`Unable to find compatible target in system image.` when using valgrind

[JeffBezanson]

If there's a trick to making this work, it should be added to the valgrind devdocs.

[vchuravy]

This is most likely do to valgrind intercepting cpuid. I found a couple of reports online [1,2] possible solution is to change JULIA_CPU_TARGET to the lowest common denominator. From a cursorary glance at the valgrind release notes it claims to support avx2 so maybe sandybridge will work. Otherwise we have to figure out what flags it actually sets and construct the appropriate cpu target. Related issue #24693 and #21849 (comment)

[1] https://stackoverflow.com/questions/48697579/valgrind-changes-cpuid-value
[2] https://sourceforge.net/p/valgrind/mailman/message/31960632/

[Keno]

Both valgrind and rr mask out cpuid values we don't really care about. We should adjust the processor detection code to ignore those. In the meantime @JeffBezanson you can comment out that error message and set match_idx to 0, which'll work just fine.

[JeffBezanson]

Yes, that's what I do now. We should implement and/or document a real solution.

[yuyichao]

These are probably not used by LLVM so ignoreing these now is OK but I don't think that's a good idea in the long term since user code might want to use them after the CPU detection API is exposed to julia code.

The current way I deal with this is to make sure I have a target compiled that doesn't have all those features enabled. Other "more out of the box" solutions that I've considered (but decided to not do any until someone actual complain since none of them are perfect) includes.

1. Do something special when running under rr/valgrind.

   This will be quite messy especially when those projects discovers more features that they want to disable. Old versions of julia won't handle those. Also, who knows what other tools may appear that has the same problem with it's own set of features to disable.

2. Similar to above, but unconditionally disable these features by default. Requiring those to be enabled explicitly, even for native target.

   This will make it harder for future users to enable these features and also suffer from the same problem of synchronizing with other projects.

3. Change default build target to general;native instead of native.

   For most users/developers this should just work out of the box (and is essentially what I do sometimes). This will cause problem when debugging a LLVM backend problem though since it won't load the same version of sysimg.

4. Add an cmdline option/env to force loading a certain version from sysimg, ignoring all the compatibility checks.

   As a dev only feature that needs to be explicitly specified it's not as bad as silently ignoring missing features even when those have potential users in the future. It's also kind of fun to see how far can a version go on a unsupported hardware without sigill............

[Keno]

At least for the purposes of loading the sysimg we should ignore all the instructions llvm doesn't use. If an when user code starts using the cpuid code, we can come up with a better solution.

[JeffBezanson]

I'd consider this developer-only, so we don't need to make any drastic changes like changing the default target to support it. Even rebuilding the system image would be fine. A hidden command line option would be fine too. Mostly just needs to be documented in devdocs/valgrind.md.

[nalimilan]

In case somebody is having a hard time running Julia with Valgrind, rebuilding the sysimage for the generic target (on x86_64) works. The manual should probably mention this.