The build error matches that from Issue 786760

../../third_party/ffmpeg/libavcodec/x86/cabac.h:193:9: error: inline assembly requires more registers than available
        BRANCHLESS_GET_CABAC("%0", "%q0", "(%4)", "%1", "%w1",

The fix used for that issue was to set HAVE_EBP_AVAILABLE = 0 for sanitizer builds. Expanding that fix to linux x86 would presumably fix the issue, but it isn't clear to me why thats needed. 

In this case the bot is not using a santizer. The gn args there are simply

goma_dir = "/b/c/goma_client"
is_component_build = true
is_debug = true
strip_absolute_paths_from_debug_symbols = true
target_cpu = "x86"
use_goma = true


IIUC EBP is generally available in x86 builds, so not sure what's happened in this case. 

 Issue 799042  has been merged into this issue.

I'm surprised it doesn't compile in Chrome since build_ffmpeg.py for linux x86 works. is_debug should be prevented from removing -O2, but maybe that isn't working right.

https://cs.chromium.org/chromium/src/third_party/ffmpeg/BUILD.gn?l=205

There may be some other cflag we need to nuke for debug. Otherwise expanding the ebp fix seems reasonable.

 Issue 799820  has been merged into this issue.

liberato/chcunningham@ over to y'all to triage further in M68.

By experimenting with the cflags setting in obj/third_party/ffmpeg/ffmpeg_internal.ninja, I found that EBP is unavailable when the "-mstackrealign" parameter is passed to the compiler.

The build_ffmpeg.py script does not enable -mstackrealign, but the chrome build system does, leading to this mismatched behavior.

Thanks for investigating. It looks like -mstackrealign comes from here:

https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?l=1077

+thestig who worked on issue 418554, it seems like we can either remove this config for linux && x86 or if it's needed set HAVE_EBP_AVAILABLE=0 when present. @thestig do you have a recommendation?

If Chrome no longer needs to support Linux systems with old versions of glibc that misalign their stacks, then we should be able to remove -mstackrealign, which I think was originally added for https://crbug.com/418554.

rnk: Which versions of glibc has the misaligned stacks issue? It's been a while and I don't remember much of bug 418554.

Do we still ship 32-bit linux binaries other than on cros? If not, we can probably remove it and see if anyone complains.

Don't we always bundle libc++ now? 

glibc is the C standard library, not the C++ one. We still depend on glibc :-)

Hah, that makes sense in retrospect.

We do not ship 32-bit Linux binaries anywhere, and haven't for a long time (M48 was the last release).

Ubuntu 16.04+ and Debian 9+ still ship modern 32-bit Chromium. Maybe this issue does not affect them because they don't ship proprietary codecs?

Gentoo Linux still supports building 32-bit x86 Chromium, and we (optionally) enable proprietary codecs.

We received a bug report about this issue in May, and I just got around to implementing a workaround (disabling EBP).

https://bugs.gentoo.org/656902
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4df468253f85ead4ce444e2d4945d2457181606b

Ubuntu works around the issue with a similar patch.

https://bazaar.launchpad.net/~chromium-team/chromium-browser/bionic-stable/view/head:/debian/patches/fix-ffmpeg-ia32-build.patch

Do your 32-bit binaries work fine if you remove the contents of this if: https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?type=cs&q=mstackrealign+file:%5C.gn&sq=package:chromium&g=0&l=1084 ?

gcc added an ABI break long ago, but by now all glibcs in the wild have probably been rebuilt and this might no longer be needed. That should fix ffmpeg too, and will help with binary size and perf and whatnot.

I built with:

is_component_build = false
is_debug = false
target_cpu = "x86"
proprietary_codecs = true
ffmpeg_branding = "Chrome

and the if-block in build/config/compiler/BUILD.gn removed.

The resulting binary works in Debian 9 and can play a mp4 video.

So we can probably remove clang_stackrealign altogether? https://chromium-review.googlesource.com/1150452

CL in CQ. Let's see what happens...

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bc19af569170611b8f0bfec45f38ba7a03a8ea7d

commit bc19af569170611b8f0bfec45f38ba7a03a8ea7d
Author: Lei Zhang <thestig@chromium.org>
Date: Wed Jul 25 21:44:31 2018

Remove clang_stackrealign config.

It is no longer needed on modern Linux distros.

If this breaks your 32-bit Linux build, please comment on
 https://crbug.com/796379 

BUG=418554,556393, 796379 

Change-Id: I07327271e607c3c7e3f9ebd755c6f7cf4537480e
Reviewed-on: https://chromium-review.googlesource.com/1150452
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578077}
[modify] https://crrev.com/bc19af569170611b8f0bfec45f38ba7a03a8ea7d/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/bc19af569170611b8f0bfec45f38ba7a03a8ea7d/build/config/compiler/BUILD.gn
[modify] https://crrev.com/bc19af569170611b8f0bfec45f38ba7a03a8ea7d/components/crash/content/app/BUILD.gn
[modify] https://crrev.com/bc19af569170611b8f0bfec45f38ba7a03a8ea7d/third_party/breakpad/BUILD.gn

Thanks Lei!