[Ffmpeg-devel] sse sigsegv and libavcodec/wmadec.c

Benjamin Larsson banan
Thu Dec 7 10:16:22 CET 2006


Rich Felker skrev:
> On Wed, Dec 06, 2006 at 04:08:34PM +0100, Michael Niedermayer wrote:
>   
>>> Hi, do you have any good suggestion how this can be fixed without fixing 
>>> the compiler. This affects all codecs that needs aligned float buffers 
>>> when using sse on windows (and other platforms). We could try to 
>>> manually align the contexts (hacky but could work) or should we disable 
>>> sse on platforms with broken compilers ?
>>>       
>> why exactly does gcc on windows fail to provide the specified alignment while
>> it works on linux? are all gcc versions affected?
>> if its just gcc 3 then id say drop official gcc 3 support for windows
>>     
>
> It's actually a gcc bug and it affects all systems except ones which
> implement nonstandard GNU abi semantics, i.e. glibc. The problem is
> that gcc makes no effort to actually align the stack but assumes that
> it's aligned to begin with and that all function calls will keep it
> aligned. This requires both the libc startup code (crt0.o or whatever)
> to align the stack, and for all code to be compiled with a compiler
> that wastes stack space and instructions to keep the stack aligned.
>
> The only correct implementation is for the compiler to make no
> assumption about stack alignment (beyond the mandatory word alignment
> that's existed in the i386 abi ever since the beginning) and always
> align the stack itself in the case where there are automatic variables
> needing more stringent alignment than the default. Anything else will
> break when linked with code from different compilers, startup code
> from non-glibc-compliant systems, asm, etc.
>
> If gcc devs refuse to fix their broken shit, I only see two possible
> solutions:
>
> 1. disable sse
> 2. work around it by writing our own crap to align it...
>
> Rich
>   
How about to malloc all "sse" buffers. We are talking about 2-3 buffers 
in 1or 2 codecs.

MvH
Benjamin Larsson




More information about the ffmpeg-devel mailing list