Re: binutils builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

[Mark Wielaard <mark@klomp.org>]

Hi,

A small update. Announcing two new builders.

On Sun, 2022-05-01 at 18:37 +0200, Mark Wielaard wrote:
> https://builder.sourceware.org now has 6 binutils builders:
> https://builder.sourceware.org/buildbot/#/builders?tags=binutils
> debian-amd64, fedora-x86_64, fedora-s390x, debian-ppc64, debian-armhf
> and debian-arm64.  I like to add a fedora-ppc64le one once that one
> has enough disk space.
> 
> The first two are configured with --enable-targets=all. The others
> not because they are too slow and/or --enable-targets=all causes
> extra failures.
> 
> All build all-gas all-ld all-bintuils all-gold fine.  fedora-x86_64
> and binutils-debian-ppc64 pass the whole testsuite check-gas check-ld
> check-binutils.
> 
> The gas and binutils testsuites seem clean on all builders. But the ld
> testsuite does see some unexpected failures or passes on some
> builders. It would be great if we could fix these. If not it might
> make sense to run the ld testsuite separately.
> 
> Note that you can see the used linux kernel, gcc, binutils versions on
> the workers page:
> https://builder.sourceware.org/buildbot/#/workers
> 
> binutils-fedora-s390x
> https://builder.sourceware.org/buildbot/#/builders/binutils-fedora-s390x
> has 2 unexpected ld failures:
> FAIL: Run pr19719 fun undefined
> FAIL: pr26580-3
> 
> binutils-debian-amd64
> https://builder.sourceware.org/buildbot/#/builders/binutils-debian-amd64
> has 2 unexpected ld failures:
> FAIL: Run p_align-1b with PIE
> FAIL: Run p_align-1d with -Wl,-z,max-page-size=0x1000 with PIE
> 
> binutils-debian-arm64
> https://builder.sourceware.org/buildbot/#/builders/binutils-debian-arm64
> has 1 unexpected success:
> XPASS: Run pr19719 fun undefined
> 
> binutils-debian-armhf
> https://builder.sourceware.org/buildbot/#/builders/binutils-debian-armhf
> has 8 unexpected ld failures and 7 unexpected successes
> XPASS: Run pr19719 fun undefined
> FAIL: Common symbol override ifunc test 1a
> FAIL: Common symbol override ifunc test 1b
> FAIL: Run pr18841 with libpr18841b.so
> FAIL: Run pr18841 with libpr18841c.so
> FAIL: Run pr18841 with libpr18841bn.so (-z now)
> FAIL: Run pr18841 with libpr18841cn.so (-z now)
> FAIL: Run pr23169a
> FAIL: Run pr23169d
> XPASS: visibility (hidden_undef) (non PIC)
> XPASS: visibility (hidden_undef) (non PIC, load offset)
> XPASS: visibility (hidden_undef) (PIC main, non PIC so)
> XPASS: visibility (protected_undef) (non PIC)
> XPASS: visibility (protected_undef) (non PIC, load offset)
> XPASS: visibility (protected_undef) (PIC main, non PIC so)
> 
> The binutils-debian-armhf builder is also the slowest (takes 15
> minutes). The rest take a few minutes. They should sent email once a
> new failure occurs (or if one if the currently failing builders starts
> passing).

All the above failures are still an issue, but there is now a 
binutils-fedora-ppc64le which is fully green:
https://builder.sourceware.org/buildbot/#/builders/binutils-fedora-ppc64le

So binutils-debian-ppc64, binutils-fedora-ppc64le and binutils-fedora-
x86_64 are fully green. But binutils-debian-amd64, binutils-debian-
arm64, binutils-debian-armhf and binutils-fedora-s390x show one or more
make check failures (but all build):
https://builder.sourceware.org/buildbot/#/builders?tags=binutils

> There is also one build and check everything builder
> https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-fedrawhide-x86_64
> I haven't looked at the test results yet, but they are all stored in
> the bunsendb.git for later analysis. This builder doesn't sent emails
> on bad builds. It also takes a very long time to run (from 1 to 7
> hours).

Frank seems to have gotten a handle on this and full builds/tests now
take ~1 hour. He also added a builder that uses clang so you can easily
compare test results (in bunsendb.git, no logs yet in the buildbot
itself) against an alternative compiler:
https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-clang-fedrawhide-x86_64

Cheers,

Mark