[MPlayer-dev-eng] [RFC] rc2

Michael Niedermayer michaelni at gmx.at
Mon Apr 9 03:31:54 CEST 2007


Hi

On Mon, Apr 09, 2007 at 12:23:09AM +0000, Arpi wrote:
> Hi,
> 
> > theres nothing lavc specific here, SSE* code needs aligned data outside
> > lavc too
> > 
> > 
> > > (win only? 
> > 
> > > can it happen with mplayer?)
> > 
> > if (gcc doesnt maintain alignment || main or another entry point like thread
> > stuff is called with missalged stack && gcc doesnt align the stack) && the
> > stack is used for something which needs proper alignment
> > 
> > the gcc behavior depends on version and flags given to it (and no i dont know
> > the details RTFgccM )
> 
> it was (and probably still is) a problem with mingw32-compiled win32
> mplayer binaries. cygwin has no problem, it uses own memory allocator,
> but mingw relies on windows' memory functions which has no memalign() :(
> 
> there was 2 ideas to solve this, one is using some 3rd-party memory library
> when compiling with mingw, the other is changing all the code (mostly in
> libavcodec) which needs alignment to do the alignment for itself, like:
>   buffer1_base=malloc(buffer1_size+15);
>   buffer1=(buffer1_base+15)&(~15);
> but it's quite ugly and hackish, and as only win32/mingw needs it nobody
> would support it...   the workaround is/was to disable sse in mingw builds :(

lav* uses av_malloc() which takes care of aligning if theres no other way
to get aligned data (memalign() or malloc())
roberto was (if i understood him correctly) talking about stack alignment

gcc before 4.something simply assumed correct alignment on function entry
which is not true under some circumstances on win32 (ive no faint clue
when or if theres a relation to mingw/cygwin ...)
(and xine on linux with their overriden -mpreferred-stack-boundary too breaks
stack alignment on entry to lavc functions and there are probably other cases
...)

the only reason why things dont completely fall apart is that theres not much
code which needs a aligned stack, still there is some, mostly mmx though and
that dosnt die its just slower :(
so ive added a warning message to lavc a while ago which warns the loo/u-ser
about the problem if a missaligned stack is detected
though it seems the message could benefit from being rewritten to be more
understandable

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070409/10c26a66/attachment.pgp>


More information about the MPlayer-dev-eng mailing list