Probably, yes.

However, please note that valgrind emulates a pentium-classic, thus, if you optimize for anything else, say, -march=pentiumpro or similar, things tend to break.

Also, it is not possible to run valgrind on applications using GL if you have the nVidia drivers (this includes all applications linked against such things as qt, since it pulls in the GL libraries) since the nvidia drivers use sse and mmx, and maes the rather sane assumption that at least mmx is available.

Same goes for mplayer, since many of the windows codecs use mmx.

/ Per Hedbor ()

Previous text:

2002-12-11 23:07: Subject: gcc 3.2

---

Good idea - it's not the valgrind include, anyway.

(valgrind 1.0.4, optimized pike with everything but no special include)

| disInstr: unhandled opcode 0xCC then 0x5 | | valgrind: the `impossible' happened: | unhandled x86 opcode | Basic block ctr is approximately 6100000 | | sched status: | | Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 | ==22864== at 0x2DA60654: ??? | ==22864== by 0x2E0246D1: ??? | ==22864== by 0x8071427: apply_low_safe_and_stupid (in /home/mirar/pike/orchid/test-install/pike/7.5.1/bin/pike) | ==22864== by 0x812CAC9: eval_low (in /home/mirar/pike/orchid/test-install/pike/7.5.1/bin/pike)

Might be machine code?

/ Mirar

In the last episode (Dec 12), Martin Stjernholm, Roxen IS @ Pike developers forum said:

Hooking onto mprotect(2) would probably help but it's not a 100% solution since afaics there's no system call that has to be issued when some previously executed memory is overwritten and executed again.

Cache flushing is machine-dependant, and I /think/ the x86 CPUs do bus snooping so caches are always valid. Just make sure there are calls to VALGRIND_DISCARD_TRANSLATIONS whenever you change code, and valgrind should be happy.