Date: Fri, 9 May 2014 12:11:32 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Dimitry Andric <dim@freebsd.org> Cc: chromium@freebsd.org, Pedro Giffuni <pfg@freebsd.org> Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses Message-ID: <CAJ-VmoknOe8d9H5o8D1XMWn%2Bq%2B_aJ-B46URwkOsnVkWAXEhamw@mail.gmail.com> In-Reply-To: <9810619D-DF65-4A4F-9720-B22DC791EA65@FreeBSD.org> 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> <9810619D-DF65-4A4F-9720-B22DC791EA65@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
There's an alignment hack option in the ffmpeg port though. It's not a cflags thing, it's a ./configure thing. -a On 9 May 2014 11:40, Dimitry Andric <dim@freebsd.org> wrote: > I just tried building multimedia/ffmpeg on i386-freebsd11, with the defau= lt port settings, and it seems to work just fine. I tried transcoding a fe= w files, and there were no stack alignment problems or SIGBUSes. > > Looking at the build logs, I see > > C compiler cc > ARCH x86 (generic) > big-endian no > runtime cpu detection yes > yasm yes > MMX enabled yes > MMXEXT enabled yes > 3DNow! enabled yes > 3DNow! extended enabled yes > SSE enabled yes > SSSE3 enabled yes > AVX enabled yes > FMA4 enabled yes > i686 features enabled yes > CMOV is fast no > EBX available yes > EBP available yes > ... > > The command line flags used for compilation (wrapped for clarity) don't s= eem to include specific ones that change stack alignment behavior: > > cc \ > -I. \ > -I./ \ > -DLIBICONV_PLUG \ > -D_ISOC99_SOURCE \ > -D_FILE_OFFSET_BITS=3D64 \ > -D_LARGEFILE_SOURCE \ > -DHAVE_AV_CONFIG_H \ > -O2 \ > -pipe \ > -march=3Dcorei7 \ > -DLIBICONV_PLUG \ > -fno-strict-aliasing \ > -msse \ > -I/usr/local/include/vorbis \ > -I/usr/local/include \ > -std=3Dc99 \ > -fomit-frame-pointer \ > -I/usr/local/include \ > -I/usr/local/include/freetype2 \ > -I/usr/local/include/libpng15 \ > -I/usr/local/include \ > -I/usr/local/include/p11-kit-1 \ > -I/usr/local/include/freetype2 \ > -I/usr/local/include/libpng15 \ > -I/usr/local/include/opencv \ > -I/usr/local/include \ > -I/usr/local/include/schroedinger-1.0 \ > -I/usr/local/include/orc-0.4 \ > -Wdeclaration-after-statement \ > -Wall \ > -Wno-parentheses \ > -Wno-switch \ > -Wno-format-zero-length \ > -Wdisabled-optimization \ > -Wpointer-arith \ > -Wredundant-decls \ > -Wno-pointer-sign \ > -Wwrite-strings \ > -Wtype-limits \ > -Wundef \ > -Wmissing-prototypes \ > -Wno-pointer-to-int-cast \ > -Wstrict-prototypes \ > -O3 \ > -fno-math-errno \ > -fno-signed-zeros \ > -Qunused-arguments \ > -Werror=3Dimplicit-function-declaration \ > -Werror=3Dmissing-prototypes \ > -Werror=3Dreturn-type \ > -MMD \ > -c \ > > I'll build chromium with the default options, and see what happens. > > -Dimitry > > On 09 May 2014, at 19: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-VmoknOe8d9H5o8D1XMWn%2Bq%2B_aJ-B46URwkOsnVkWAXEhamw>