If the movdqa instruction is used on an address which is not 16 byte aligned, the CPU will raise a GP. It'd be nice if valgrind would report this error. There may be other instructions (such as movaps, I believe) that have similar restrictions.
> If the movdqa instruction is used on an address which is not 16 byte > aligned, the CPU will raise a GP. It'd be nice if valgrind would report > this error. What signal do you get? SIGBUS?
Julian Seward wrote: > What signal do you get? SIGBUS? > GPF, which gets mapped into SIGSEGV.
I ran into this too a few days ago, apparantly GCC 4.3.4 and 4.4.3 can, under some circumstances, generate code that calls movdqa with badly aligned data addresses. Having such code running properly under Valgrind but failing when running "normally" is a bit confusing.
Quoting Julian Sevard on the Valgrind-users mailing list: > It's a 1-liner fix (for movdqa, at least); just insert a call > "gen_SEGV_if_not_16_aligned( addr )" in the memory case for movdqa, > around about line 11189 in the svn trunk. :-)
Marking as we-should-fix-this-for-3.6.0.
Fixed, vex r2057.
Looks like Valgrind introduces unaligned memory accesses itself, see https://bugs.kde.org/show_bug.cgi?id=254646 Before VEX r2057 it was ok, because those weren't really executed on the CPU (were they?), but with the explicit checks added everything broke down.