Bug 153699

Summary: Valgrind should report unaligned reads with movdqa
Product: [Developer tools] valgrind Reporter: Soren Sandmann <sandmann>
Component: generalAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: normal CC: christoffer.haglund, glider, justin.lebar
Priority: NOR    
Version: 3.2.3   
Target Milestone: wanted3.6.0   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:

Description Soren Sandmann 2007-12-08 23:45:50 UTC 
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.
Comment 1 Julian Seward 2007-12-09 03:44:10 UTC 
> 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?
Comment 2 Jeremy Fitzhardinge 2007-12-10 19:58:58 UTC 
Julian Seward wrote:
> What signal do you get?  SIGBUS?
>   


GPF, which gets mapped into SIGSEGV.
Comment 3 Christoffer Haglund 2010-08-11 13:55:53 UTC 
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.
Comment 4 Christoffer Haglund 2010-08-11 13:59:09 UTC 
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.

:-)
Comment 5 Julian Seward 2010-08-12 10:49:35 UTC 
Marking as we-should-fix-this-for-3.6.0.
Comment 6 Julian Seward 2010-09-30 16:52:07 UTC 
Fixed, vex r2057.
Comment 7 Alexander Potapenko 2010-10-20 11:16:09 UTC 
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.