<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>At 2014-04-18 03:31:38,"Jason Garrett-Glaser" <jason@x264.com> wrote:<br>>On Wed, Apr 16, 2014 at 8:50 PM, chen <chenm003@163.com> wrote:<br>>><br>>> At 2014-04-17 08:05:22,"Jason Garrett-Glaser" <jason@x264.com> wrote:<br>>>>On Wed, Apr 16, 2014 at 11:08 AM, Steve Borho <steve@borho.org> wrote:<br>>>>> On Wed, Apr 16, 2014 at 12:57 PM, Steve Borho <steve@borho.org> wrote:<br>>>>>> On Wed, Apr 16, 2014 at 12:28 PM, Jason Garrett-Glaser <jason@x264.com><br>>>>>> wrote:<br>>>>>>>> x264 manually aligns their stack (see x264_stack_align())<br>>>>>>><br>>>>>>> Note that this is because we don't require gcc's<br>>>>>>> force_arg_align_stack_pointer intrinsic (added in 4.2). The stack<br>>>>>>> isn't guaranteed to be aligned on thread entry or library entry on<br>>>>>>> x86_32, so even if gcc is told to keep stack alignment, it can only<br>>>>>>> keep stack alignment relative to the entry point, hence we have to<br>>>>>>> manually align the entry point.<br>>>>>>><br>>>>>>> Note that this is important even if you don't use x264asm, because<br>>>>>>> using alignment intrinsics on stack-allocated arrays does not work if<br>>>>>>> the entry point hasn't been aligned.<br>>>>>>><br>>>>>>> x264asm's stack alignment /should/ align relative to the values being<br>>>>>>> pushed onto the stack -- if it isn't, something's probably very wrong.<br>>>>>>> I'm going to assume it's not broken, since it's used for a good bit of<br>>>>>>> ffmpeg and x264 code, but if it is broken, poke the x264 mailing list<br>>>>>>> with assembly code and the (wrong) assembled output.<br>>>>>><br>>>>>> Would it be appropriate to simply add "-mpreferred-stack-boundary=4"<br>>>>>> for x86_32 compiles if GCC is new enough to support it, or set<br>>>>>> HAVE_ALIGNED_STACK=0 if it is too old?<br>>>>><br>>>>> Oh, your point about library entry points finally has sunk in.  We<br>>>>> need to either enforce stack alignment internally on all our thread or<br>>>>> API entry points on x86_32 builds, or we have to set<br>>>>> HAVE_ALIGNED_STACK=0 unconditionally for those builds.<br>>>><br>>>>That's not correct either.  HAVE_ALIGNED_STACK=0 is still not<br>>>>sufficient -- all your stack-declared aligned arrays will be<br>>>>misaligned and things may crash anyways. You must enforce stack<br>>>>alignment at all thread starts and entry points (well, only the ones<br>>>>that actually lead to asm code -- in x264 this is only like two<br>>>>places, so it's not a huge deal!). osdep.h in x264 covers stack<br>>>>alignment for stack-declared arrays which require higher alignment<br>>>>than the stack's native alignment.<br>>>><br>>>>Note something important:<br>>>><br>>>>1.  The way gcc enforces stack alignment for aligned elements on the<br>>>>stack is to keep the stack aligned between functions, then align<br>>>>elements on the stack relative to the aligned stack. This fits with<br>>>>the Linux userspace convention that stacks should be 16-byte aligned<br>>>>on x86_32.<br>>>><br>>>>2.  On ICC (and I presume MSVC), instead, data on the stack is aligned<br>>>>explicitly, without making assumptions about the stack pointer's<br>>>>alignment. This is slower, but works without such a convention.<br>>>><br>>>>So this is a non-MS compiler issue only. Note this comes up double<br>>>>e.g. on ARM, where the compiler does not even support anything above<br>>>>8-byte alignment, or worse, 4-byte alignment on iOS's ABI. This is why<br>>>>osdep.h has those workarounds.<br>>>><br>>>>Jason<br>>> :<br>>><br>>> in our code, we use more than 4 regs in x86 mode, so we have to save some<br>>> regs onto stack.<br>><br>>x86inc handles this already when it references values in the stack.<br>>If it didn't, none of x264's asm would function.<br>><br>yes, for value only</div>
<div>it didn't align stack for reserve stack space (4th parameters of cglobal)</div>
<div> </div></div>