[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c

[Uoti Urpala]

On Sun, 2007-03-25 at 20:57 -0700, Roman Shaposhnik wrote:
>   Such files, for example, would be generated by gcc when you do -Os.

gcc did that with -Os earlier, but I think that is considered to have
been a bug in -Os. -Os does not change -mpreferred-stack-boundary in
4.1.2, and probably will not change it in future versions either.

>   I don't understand it -- how can you "ensure stack alignment while
> running FFmpeg code" by "using the gcc 4.2+ attributes" on a system
> where all you have control over is just how the libavcodec.so or
> libavcodec.dll is built ? 

-mstackrealign
    Realign the stack at entry.  On the Intel x86, the -mstackrealign
    option will generate an alternate prologue and epilogue that
    realigns the runtime stack.  This supports mixing legacy codes that
    keep a 4-byte aligned stack with modern codes that keep a 16-byte
    stack for SSE compatibility.  The alternate prologue and epilogue
    are slower and bigger than the regular ones, and the alternate pro?
    logue requires an extra scratch register; this lowers the number of
    registers available if used in conjunction with the "regparm"
    attribute.  The -mstackrealign option is incompatible with the

If you compile with the above option then I assume the code will work
with any calling stack alignment but possibly with a noticeable
performance penalty. Setting the corresponding function attribute only
for functions that can be entry points from an external application
would be more work but should eliminate most of the performance penalty.