[x265] ASM crash in r6706

Jason Garrett-Glaser jason at x264.com
Sat Apr 19 03:40:54 CEST 2014


On Fri, Apr 18, 2014 at 11:03 AM, chen <chenm003 at 163.com> wrote:
> At 2014-04-19 01:47:16,"Jason Garrett-Glaser" <jason at x264.com> wrote:
>
>>> In this case, they pass a align stack to our code, but cglobal push 3
>>> registers, so broken stack align.
>>
>>I don't understand what you mean.  x264asm knows what the stack
>>alignment is, so when it allocates scratch space, it references
>>aligned locations on the stack.  It doesn't matter how many registers
>>it pushes; if it pushes 12 bytes of registers, it references locations
>>that are 12 bytes off from where it would if there were no registers
>>pushed.
>>
>>"esp" itself may not be aligned, but that's fine, because no data is
>>ever accessed directly from esp -- it's accessed from aligned
>>locations on the stack.  That's how stack alignment works. esp only
>>needs to be aligned if the function calls another function, but
>>x264asm is for leaf functions, so that doesn't apply.
>>
> In the x264asm header, I found the doc "%4 = (optional) stack size to be
> allocated. If not aligned,  the stack will be manually aligned (to 16 or 32
> bytes)"
> I guess it means we can alloc some space on stack, and x264asm will let it
> align to 16 ort 32 bytes bound, am I right?
>
> In this case, x264asm don't do it because HAVE_ALIGNED_STACK=1
> the input stack is aligned, but we need push 3 regs into stack, so we got a
> stack mistake.

Again, that's not how it works.

HAVE_ALIGNED_STACK means x264asm can assume the input stack is aligned.

It does not mean x264asm magically stops handling stack alignment.

HAVE_ALIGNED_STACK exists to compensate for compilers such as Intel's
that don't perform stack alignment.  It has _absolutely nothing_ to do
with x264asm's own pushing registers onto the stack.

Jason


More information about the x265-devel mailing list