Summary: | Wrapped functions cause stack misalignment on OS X (and possibly Linux) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Alexander Potapenko <glider> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bart.vanassche+kde, eugeni.stepanov, konstantin.s.serebryany, tom |
Priority: | NOR | ||
Version: | 3.6 SVN | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Preserve esp/rsp 16-alignment on x86/amd64 platforms |
Description
Alexander Potapenko
2010-10-19 12:55:02 UTC
Looks like this was brought by r2057 (which fixes https://bugs.kde.org/show_bug.cgi?id=153699), particularly the following diff: ----------------------- Index: priv/guest_x86_toIR.c =================================================================== --- priv/guest_x86_toIR.c (revision 2056) +++ priv/guest_x86_toIR.c (revision 2057) @@ -10037,6 +10046,7 @@ } else { addr = disAMode( &alen, sorb, delta+2, dis_buf ); delta += 2+alen; + gen_SEGV_if_not_16_aligned( addr ); storeLE( mkexpr(addr), getXMMReg(gregOfRM(modrm)) ); DIP("movdqa %s, %s\n", nameXMMReg(gregOfRM(modrm)), dis_buf); } ----------------------- This means that the wrappers were broken long ago, but the error wasn't reported properly. Side note: the proposed test case works for me only in 32-bit mode. What are the required alignments, for 32- and 64-bit processes? SSE requires 16-byte data alignment for both 32-bit and 64-bit. Yet again, the reported problem also happened to us on 64-bit platforms (Linux and NaCl), but is a bit harder to reproduce. The required alignment is defined by the various ABIs. For amd64 the ABI document (http://www.x86-64.org/documentation/abi.pdf) says: In addition to registers, each function has a frame on the run-time stack. This stack grows downwards from high addresses. Figure 3.3 shows the stack organization. The end of the input argument area shall be aligned on a 16 (32, if __m256 is passed on stack) byte boundary. In other words, the value (%rsp + 8) is always a multiple of 16 (32) when control is transferred to the function entry point. That's the linux ABI of course, so the Mac one might be different. (In reply to comment #5) > That's the linux ABI of course, so the Mac one might be different. Sure; but if we stick to the rule that if we move %rsp or %esp then it must be by a multiple of 16 bytes, then everything would be OK, I think. That would preserve whatever alignment was there originally, up to and including 16-alignment. This assumes that neither Linux nor Darwin requires more than 16-alignment, but I can't see that being the case, at least for now. Created attachment 52703 [details]
Preserve esp/rsp 16-alignment on x86/amd64 platforms
Alexander, can you try this patch?
(In reply to comment #7) This works for me on Mac OS 10.5, thanks! > Created an attachment (id=52703) [details] > Preserve esp/rsp 16-alignment on x86/amd64 platforms > > Alexander, can you try this patch? Both 32- and 64-bit ? Fixed, r11461. We're still having the same problem in ThreadSanitizer after updating to Valgrind 11461, see http://code.google.com/p/data-race-test/issues/detail?id=49 However Helgrind works with this patch. (In reply to comment #11) > We're still having the same problem in ThreadSanitizer after updating to > Valgrind 11461, Do you have a way to reproduce this with a vanilla, unmodified Valgrind trunk now? (In reply to comment #12) > Do you have a way to reproduce this with a vanilla, unmodified Valgrind > trunk now? Just run none/tests/pending.vgtest: $ perl tests/vg_regtest none/tests/pending >&/dev/null $ cat none/tests/pending.stderr.diff --- pending.stderr.exp 2011-02-12 13:07:20.000000000 +0100 +++ pending.stderr.out 2011-03-06 11:38:29.000000000 +0100 @@ -1,2 +1,9 @@ +Process terminating with default action of signal 11 (SIGSEGV) + General Protection Fault + at 0x........: dyld_stub_binder (in /...libc...) + by 0x........: ??? (in ./pending) + by 0x........: ??? + by 0x........: (below main) + I believe this has been fixed properly by r12461 and 12462, so I'm going to close it. Please reopen if it's still a problem. |