Summary: | media-video/ffmpeg: fails to build on and64 hardened system when CFLAGS+=-fstack-check | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anthony Basile <blueness> |
Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | bertrand, hardened, klondike, media-video |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=482258 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | This patch fixes the issue by using matrix addressing instead (whose cost is negligible anyways). |
Description
Anthony Basile
2013-05-29 22:16:56 UTC
Created attachment 349600 [details, diff]
This patch fixes the issue by using matrix addressing instead (whose cost is negligible anyways).
This is quick and dirty patch that should do the trick, it basically removes the hack of caching some coefficients letting the L1 cache handle that instead. The impact should be negligible or even a small win for the smaller register pressure.
(In reply to Francisco Blas Izquierdo Riera from comment #1) > Created attachment 349600 [details, diff] [details, diff] > This patch fixes the issue by using matrix addressing instead (whose cost is > negligible anyways). > > This is quick and dirty patch that should do the trick, it basically removes > the hack of caching some coefficients letting the L1 cache handle that > instead. The impact should be negligible or even a small win for the smaller > register pressure. please submit it upstream; see http://ffmpeg.org/developer.html#Submitting-patches-1 they will probably ask you for a benchmark before & after the patch Taking into account that "The main priority in FFmpeg is simplicity and small code size in order to minimize the bug count." and the hack my patch reverted goes against the concept of simplicity I don't feel very compelled to send them the patch right now. (In reply to Francisco Blas Izquierdo Riera from comment #3) > Taking into account that "The main priority in FFmpeg is simplicity and > small code size in order to minimize the bug count." and the hack my patch > reverted goes against the concept of simplicity I don't feel very compelled > to send them the patch right now. I would be okay with a local patch for our hardened users when 4.8.1 brings in -fstack-check. Something contingent on USE="hardened" so we don't burden other people with needs. But! Did we at least test that that code works? I'm not sure how to trigger that code. (In reply to Anthony Basile from comment #4) > But! Did we at least test that that code works? I'm not sure how to > trigger that code. that code seems to be used for decoding the following audio files: MLP (Meridian Lossless Packing) TrueHD not sure where to find mlp samples but these seem to be truehd samples: http://samples.mplayerhq.hu/A-codecs/TrueHD/ ffmepg 1.2.6 build fine for me. Can some one more test? And what useflags? (In reply to Magnus Granberg from comment #6) > ffmepg 1.2.6 build fine for me. > Can some one more test? > And what useflags? I am not able to reproduce with 1.2.6 using gcc-4.8.2 with -fstack-check. I'm not sure what changed. Here are my USE flags: USE="3dnow 3dnowext X aac alsa amr bluray bzip2 cdio cpudetection encode gnutls gsm hardcoded-tables iconv jack jpeg2k libass libcaca libv4l mmx mmxext modplug mp3 network openal oss pic pulseaudio rtmp schroedinger sdl speex ssse3 static-libs theora threads v4l vaapi vorbis vpx xvid zlib -aacplus -bindist -debug -doc -examples -faac -fdk -flite -fontconfig -frei0r -iec61883 -ieee1394 -libsoxr -openssl -opus -truetype -twolame" FFTOOLS="aviocat cws2fws ffeval fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart trasher" (In reply to Anthoine Bourgeois from comment #8) > See Also: > https://bugs.gentoo.org/show_bug.cgi?id=471756 https://bugs.gentoo.org/show_bug.cgi?id=506206 Sorry :-/ Rather than trying to fix the asm which will get no where upstream (and we're not even sure will work as intened), let's go with the same solution as for media-video/libav in bug #482258. Basically we need to add something like + if [[ ${ABI} == amd64 ]] && gcc-specs-stack-check; then + append-flags $(test-flags -fno-stack-check) + fi + before we actually compile. I'm a bit lost: what versions of ffmpeg currently in tree are actually affected by this ? tried again with upstream's help: gcc-4.7.4 fails, 4.8.4 & 4.9.2 are fine. This seems a gcc bug. Since gcc 4.8.3 is stable, maybe we can close this bug as obsolete? (In reply to Alexis Ballier from comment #12) > tried again with upstream's help: > gcc-4.7.4 fails, 4.8.4 & 4.9.2 are fine. This seems a gcc bug. Since gcc > 4.8.3 is stable, maybe we can close this bug as obsolete? It is possible that 4.8 & 4.9 are making better use of the registers so ffmpeg's aggressive use doesn't exhaust them. I haven't retested, but I do remember hitting this with 4.7, so I believe you of course that its fixed in 4.8. Go ahead and close. (In reply to Anthony Basile from comment #13) > (In reply to Alexis Ballier from comment #12) > > tried again with upstream's help: > > gcc-4.7.4 fails, 4.8.4 & 4.9.2 are fine. This seems a gcc bug. Since gcc > > 4.8.3 is stable, maybe we can close this bug as obsolete? > > It is possible that 4.8 & 4.9 are making better use of the registers so > ffmpeg's aggressive use doesn't exhaust them. I haven't retested, but I do > remember hitting this with 4.7, so I believe you of course that its fixed in > 4.8. Go ahead and close. yep, i should have phrased it as such instead of 'gcc bug' since inline asm spec is defined by what gcc accepts :) closing as obsolete |