valgrind claims to support 3dnow! in cpuid, but doesn't

[Bradley Baetz]

See https://bugs.kde.org/show_bug.cgi?id=291568 - on AMD CPUs, valgrind exposes a cpuid that shows 3dnow support, however valgrind doesn't actually support those instructions.

This results in IR decoding errors when using valgrind on ffmpeg-related apps (in my case, mythtv).

I get:

vex amd64->IR: unhandled instruction bytes: 0xF 0xF 0xC1 0xBF 0xF 0xF 0xD3 0xBF

(In this case, this is the PAVGUSB instruction)

The "fix" is in https://bugs.kde.org/show_bug.cgi?id=291568, which masks out the appropriate CPUID bit so that 3dnow isn't claimed as present. A bit hackish, but since its upstream....

Ubuntu 12.04, valgrind 1:3.7.0-0ubuntu3

[Reimar Döffinger (reimar-doeffinger)]

Created attachment 67842
Remove 3dnow support bits from CPUID

Currently the CPUID values for this are based on a real CPU.
Unfortunately, it is an AMD CPU.
This means that CPUID claims to support 3DNOW while it actually doesn't.
As a result, any program doing audio decoding with FFmpeg crashes in valgrind in x86_64 mode.
Attached patch just hacks the CPUID a bit to remove the 3DNOW flags.
That is not perfect since it now matches no real CPU but claiming to support a feature that will certainly crash is surely worse.

[Reimar Döffinger (reimar-doeffinger)]

Sorry to be impatient, but I'd appreciate if someone could have a look. This is a really old issue I got finally annoyed enough about to debug (as a MPlayer/FFmpeg developer using an AMD CPU it is really annoying when valgrind crashes the program you're debugging half the time).

[Jseward (jseward)]

Committed w/ extra comments, r2259. Thanks.