utils/genrandconfig: filter microblaze GCC < 8 bug

Works around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
which is an issue where the Microblaze archtecture had code that caused a infinite recursion while optimizing in versions of GCC less then 8.x. More BR discussion can be found on this thread.
http://buildroot-busybox.2317881.n4.nabble.com/autobuild-buildroot-net-Build-results-for-2018-04-25-td192721.html

---

Note: I do not have a good way to test this.

---
 utils/genrandconfig | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

index 06701ce..bf7c4bc 100755
@@ -320,6 +320,21 @@ def fixup_config(configfile):
     if 'BR2_or1k=y\n' in configlines and \
        'BR2_PACKAGE_QT_GUI_MODULE=y\n' in configlines:
         return False
+    # The microblaze uclibc build hangs on GCC < 8.x (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180)
+    # http://autobuild.buildroot.net/results/40d/40d33ff9e3367a22253c58b388c77d9858981bff/
+    if 'BR2_PACKAGE_BOOST=y\n' in configlines and \
+       BR2_TOOLCHAIN_EXTERNAL_URL + 'br-microblaze-full-2018.02-891-g046c5e2.tar.bz2"\n' in configlines:
+        return False
+    # The microblaze uclibc build hangs on GCC < 8.x (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180)
+    # http://autobuild.buildroot.net/results/424/42480ee672497a600b87e8d983e2d427befc62af/
+    if 'BR2_PACKAGE_FLARE_ENGINE=y\n' in configlines and \
+       BR2_TOOLCHAIN_EXTERNAL_URL + 'br-microblaze-full-2018.02-891-g046c5e2.tar.bz2"\n' in configlines:
+        return False
+    # The microblaze uclibc build hangs on GCC < 8.x (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180)
+    # http://autobuild.buildroot.net/results/d20/d20700bd538ba1e9d45ab8a61ecbbba1a320ef38/
+    if 'BR2_PACKAGE_GST_FFMPEG=y\n' in configlines and \
+       BR2_TOOLCHAIN_EXTERNAL_URL + 'br-microblaze-full-2018.02-891-g046c5e2.tar.bz2"\n' in configlines:
+        return False
 
     with open(configfile, "w+") as configf:
         configf.writelines(configlines)

1.9.1

You do:

echo 'support/config-fragments/autobuild/br-microblazeel-full.config,x86_64' \

while true; do
./utils/genrandconfig --toolchains-csv /tmp/toolchains.csv grep 'BR2_PACKAGE_\(BOOST\|FLARE_ENGINE\|GST_FFMPEG\)=y' .config && break
done

If it doesn't fail after a couple of minutes, it should be OK.

    if 'BR2_PACKAGE_BOOST=y\n' in configlines and \
        'BR2_microblaze=y\n' in configlines and \
        'BR2_TOOLCHAIN_GCC_AT_LEAST_8=y\n' not in configlines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Hello Matt,

I don't see why we would do autobuilder exceptions for this rather than a usual BR2_TOOLCHAIN_GCC_HAS_BUG_xyz.

If I understand correctly, we have two issues:

- gcc bug #85862, which didn't exist in gcc 6.3 and is a regression in gcc 6.4, but doesn't exist in gcc 7.x

This bug affects the build of libnss, and was handled by commit bd03966d4ebeb284ac3afb5f3b8cba13da2b9983, through the addition of BR2_TOOLCHAIN_HAS_GCC_BUG_85862.

- gcc bug #85180, which affects gcc 6.x and gcc 7.x, but is fixed in gcc 8.x. It affects packages such as flare-engine, boost and gst-ffmpeg.

So, for this one, rather than autobuilder exception, I would like to see something like this:

config BR2_TOOLCHAIN_HAS_GCC_BUG_85180
bool
default y if BR2_microblaze

and we'll adjust this with a "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_8" when gcc 8.x support is added in Buildroot.

flare-engine is not selected by any package (flare-game depends on flare-engine).

gst-ffmpeg is not selected by any package.

boost has lots of reverse dependencies however. But perhaps we can nail down the specific boost sub-option(s) that exhibit the problem, and only add the gcc bug dependency on those suboptions?

Any reason for not using this solution ?

Thomas

Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Thomas,

Sure, I'll take a look.

No firm reason, I can definitely refactor to use this approach. The only reason why we leaned this way is BR2_TOOLCHAIN_GCC_AT_LEAST_8 not being defined yet.

Matt

Thomas,

Looks like it doesn't really matter what you enable/disable for boost options as it's when the bjam tool is getting called that it gets stuck. I can start to look at all the reverse dependencies tomorrow....

(output from when I kill the bjam process)

2018-05-24T22:39:43 common.copy stage/lib/libboost_thread.so.1.66.0
2018-05-24T22:39:43 ln-UNIX stage/lib/libboost_thread.so
2018-05-24T22:40:06 /bin/sh: line 1: 22677 Terminated

PATH="/accts/mlweber1/rc-buildroot/output/host/bin:/accts/mlweber1/rc-buildroot/output/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" ./bjam -j65 -q --user-config=/accts/mlweber1/rc-buildroot/output/build/boost-1.66.0/user-config.jam
toolset=gcc threading=multi abi=sysv variant=release link=shared
runtime-link=shared -d+1 --ignore-site-config --layout=system

2018-05-24T22:40:06 make: ***

[/accts/mlweber1/rc-buildroot/output/build/boost-1.66.0/.stamp_built] Error 143

Matt

Hello,

bjam is Boost's build tool, so obviously it fails within a bjam invocation. But basically, you can just try to do a minimal Boost build, with no sub-option enabled. If that still triggers the infinite loop with Microblaze gcc, then we don't have any other choice but to add the BR2_TOOLCHAIN_GCC_HAS_BUG_xyz dependency on BR2_PACKAGE_BOOST itself, and propagate it to the reverse dependencies.

Have you tried playing around with optimization levels, and see if they all trigger this issue ? For example instead of using -Os, does the issue also appear at -O2 ?

Best regards,

Thomas

Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com