Date: Fri, 9 May 2014 20:40:42 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: chromium@freebsd.org, Pedro Giffuni <pfg@freebsd.org> Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses Message-ID: <9810619D-DF65-4A4F-9720-B22DC791EA65@FreeBSD.org> In-Reply-To: <CAJ-VmonLr6m1c-XX-cB-LiQT0JtoGv97dd6VHzYZPCC3hCxreQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_77818C29-4942-4D66-B882-4ACA291EBD67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I just tried building multimedia/ffmpeg on i386-freebsd11, with the = default port settings, and it seems to work just fine. I tried = transcoding a few files, and there were no stack alignment problems or = SIGBUSes. Looking at the build logs, I see=20 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 = seem 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? >=20 >=20 > -a >=20 >=20 > 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; >>>>=20 >>>> El 5/9/2014 5:56 AM, Adrian Chadd escribi=F3: >>>>=20 >>>>> Hi guys, >>>>>=20 >>>>> I filed a PR recently with chromium crashes in its internal = libffmpeg: >>>>>=20 >>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D189317 >>>>>=20 >>>>> What do you two think? It's that Linux 16 byte alignment on i386 = issue >>>>> that has been creeping up every few years. >>>>>=20 >>>>=20 >>>> Ouch, that's clang, right? >>>=20 >>> I gather so? It's whatever the binary package building cluster is >>> using. I think it's clang for i386. >>=20 >> For 10.x and 11.x, that should indeed be clang. >>=20 >>=20 >>>=20 >>>> I recently brought this from OpenBSD, no idea if it's related: >>>>=20 >>>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D265231 >>>>=20 >>>> For now I guess we should just patch the libffmpeg port like the = NetBSD guys >>>> did. >>>=20 >>> 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. >>=20 >> 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: >>=20 >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D38496 >>=20 >> 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 = SSE >> 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. >>=20 >> FFmpeg is one of those projects that assumes 16-byte alignment, and = also >> 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 = correct >> solution here. >>=20 >> 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 = version >> 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... >>=20 >> -Dimitry >>=20 --Apple-Mail=_77818C29-4942-4D66-B882-4ACA291EBD67 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlNtITcACgkQsF6jCi4glqMGdACgg+JWoKPFb2SSOJ80dnLpGoHn ZNUAoNj8YrswBlr5fT/TpO0zguNzMKuG =56UR -----END PGP SIGNATURE----- --Apple-Mail=_77818C29-4942-4D66-B882-4ACA291EBD67--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9810619D-DF65-4A4F-9720-B22DC791EA65>