Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 May 2014 10:59:40 -0700
From:      Adrian Chadd <adrian.chadd@gmail.com>
To:        Dimitry Andric <dim@freebsd.org>, chromium@freebsd.org, Ed Maste <emaste@freebsd.org>
Cc:        Pedro Giffuni <pfg@freebsd.org>
Subject:   Re: libffmpeg chromium crashes due to unaligned SSE accesses
Message-ID:  <CAJ-VmoniKW39fBJgE1izhizf33ANZPWadsStbV3X6FgrUT1sGQ@mail.gmail.com>
In-Reply-To: <CAJ-Vmomkzc5LQKLbM%2BoURbBH9Xz=w5i=uaTf3UEjs7wZq-Lc_w@mail.gmail.com>
References:  <CAJ-Vmo=C0dEhiK4O9Kunkg-P8ogSC_u_tsf_CQnUZMDvrXR-4g@mail.gmail.com> <536CDD30.40104@FreeBSD.org> <CAJ-Vmo=U3Ow3s728rXiEmfJZY%2BinkQRjiJ0bBvRmf0gALaCeew@mail.gmail.com> <7C272AE1-BA6E-48A9-9662-79B1030D0903@FreeBSD.org> <CAJ-VmonLr6m1c-XX-cB-LiQT0JtoGv97dd6VHzYZPCC3hCxreQ@mail.gmail.com> <CAJ-Vmomkzc5LQKLbM%2BoURbBH9Xz=w5i=uaTf3UEjs7wZq-Lc_w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
+emaste

On 9 May 2014 10:12, Adrian Chadd <adrian.chadd@gmail.com> wrote:
> cc'ing chromium@, as this bug is specifically about chrome.
>
>
> -a
>
>
> On 9 May 2014 10:09, Adrian Chadd <adrian.chadd@gmail.com> wrote:
>> What's the magic to get the normal ffmpeg port to work right?
>>
>>
>> -a
>>
>>
>> On 9 May 2014 10:05, Dimitry Andric <dim@freebsd.org> wrote:
>>> On 09 May 2014, at 18:42, Adrian Chadd <adrian.chadd@gmail.com> wrote:
>>>> On 9 May 2014 06:50, Pedro Giffuni <pfg@freebsd.org> wrote:
>>>>> Hello;
>>>>>
>>>>> El 5/9/2014 5:56 AM, Adrian Chadd escribi=C3=B3:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I filed a PR recently with chromium crashes in its internal libffmpe=
g:
>>>>>>
>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D189317
>>>>>>
>>>>>> What do you two think? It's that Linux 16 byte alignment on i386 iss=
ue
>>>>>> that has been creeping up every few years.
>>>>>>
>>>>>
>>>>> Ouch, that's clang, right?
>>>>
>>>> I gather so? It's whatever the binary package building cluster is
>>>> using. I think it's clang for i386.
>>>
>>> For 10.x and 11.x, that should indeed be clang.
>>>
>>>
>>>>
>>>>> I recently brought this from OpenBSD, no idea if it's related:
>>>>>
>>>>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D265231
>>>>>
>>>>> For now I guess we should just patch the libffmpeg port like the NetB=
SD guys
>>>>> did.
>>>>
>>>> Kind of? The x86-64 ABI requires 16 byte alignment for a lot of stuff.
>>>> The i386 32 bit ABI doesn't require 16 byte alignment as per
>>>> everything pre-Linux-in-2005ish. Linux / gcc flipped the "i386 =3D=3D =
16
>>>> byte alignment now" switch. I vaguely recall that they made
>>>> _everything_ 16 byte aligned but I can't be sure.
>>>
>>> Yes, actually the gcc guys just flipped the switch somewhere in 2008,
>>> without any consideration for backwards compatibility, and this lead to
>>> quite a bit of wailing, but they WONTFIXed it anyway:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D38496
>>>
>>> So the problem is that there are quite a lot of projects that simply
>>> assume everything on x86 has 16-byte aligned stacks, and you can use SS=
E
>>> instructions that require strict alignment (e.g. movaps) on any random
>>> stack-allocated variable.  Obviously, on i386-freebsd, that is not the
>>> case, as we still maintain the old SysV 4-byte alignment.
>>>
>>> FFmpeg is one of those projects that assumes 16-byte alignment, and als=
o
>>> has a lot of hand-written SSE assembly, either inline or in separate
>>> yasm sources.  The brute-force way of fixing trouble with alignment is
>>> to add -mstackrealign to CFLAGS, but I'm not sure if that is the correc=
t
>>> solution here.
>>>
>>> As far as I know, the current FFmpeg port seems to work OK on
>>> i386-freebsd, so maybe it could be enough to fix up the Chromium versio=
n
>>> of FFmpeg in a similar manner as the regular FFmpeg port?  I'm not sure
>>> I will have enough time to have look at it soon, though...
>>>
>>> -Dimitry
>>>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmoniKW39fBJgE1izhizf33ANZPWadsStbV3X6FgrUT1sGQ>