[FFmpeg-devel] Stack variables alignment check in libavcodec/dsputil.c

Ramiro Polla ramiro
Sun Aug 12 01:14:45 CEST 2007

Michael Niedermayer wrote:
> Hi
> On Sat, Aug 11, 2007 at 07:14:29PM -0300, Ramiro Polla wrote:
>> Michael Niedermayer wrote:
>> [...]
>>> avcodec_encode/decode_* are just small wraper functions and a register 
>>> less
>>> doesnt matter
>>> and for execute i actually would suggest to make pthread.c and co
>>> do the stack alignment so that no changes to functions which are passed
>>> to execute() are needed that practically means adding the attribute to 
>>> worker() in pthread.c
>> MinGW finally released gcc 4.2, and as promised here's my patch to fix this 
>> alignment issue (based on Ga?l Chardon's patch).
>> Zuxy, are you working on this too? Could you test it further too? 
>> Everything worked fine with all my tests (w32threads and pthreads) from 
>> within MSVC++.
> why is the realignment not always done?

If ffmpeg.c is compiled with gcc, it will align main() to 16 bytes and 
maintain alignment everywhere. If libavcodec is called from MSVC++, 
these functions will be called with 4-byte alignment. The same happens 
for threads (both in w32threads and pthreads-win32).

> what effect does it have on object size?

.text:    unpatched patched
dsputil.o 0004e270 0004e280
pthread.o 000003c0 000003d0
utils.o   000029d0 00002a30

> [...]
>> Index: libavcodec/dsputil.c
>> ===================================================================
>> --- libavcodec/dsputil.c	(revision 10074)
>> +++ libavcodec/dsputil.c	(working copy)
>> @@ -3823,7 +3823,7 @@
>>      for(i=0; i<64; i++) inv_zigzag_direct16[ff_zigzag_direct[i]]= i+1;
>>  }
>> -int ff_check_alignment(void){
>> +int attribute_align_arg ff_check_alignment(void){
>>      static int did_fail=0;
>>      DECLARE_ALIGNED_16(int, aligned);
> this IS wrong, it defeats the purpose of the function which is to check that
> the stack of the caller is properly aligned

Well, if attribute_align_arg isn't added to this function, it will still 
print out the terrorizing message but it won't ever crash due to 

Note this configure option should only be used if threads are enabled or 
the user wants to link to lav* from MSVC++, so it's not enabled by default.

Ramiro Polla

More information about the ffmpeg-devel mailing list