public inbox for buildbot@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Christophe Lyon <christophe.lyon@arm.com>
Cc: buildbot@sourceware.org
Subject: Re: Arm GCC buildbot workers
Date: Wed, 17 Aug 2022 15:00:58 +0200	[thread overview]
Message-ID: <YvzmihMu1YjgVS1I@wildebeest.org> (raw)
In-Reply-To: <45bd3411-6b54-c49e-3b6d-5cbf85a5dd10@arm.com>

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

Hi Christophe,

On Tue, Aug 16, 2022 at 01:54:00PM +0200, Christophe Lyon wrote:
> On 8/12/22 18:44, Mark Wielaard wrote:
> > The ubuntu22_04-arm64 worker seems to happily do full gcc bootstrap
> > and check builds:
> > https://builder.sourceware.org/buildbot/#/workers/34
> > 
> > It does find a couple of failing testcases, which you might want to
> > look at, but most seem expected. All results are recorded in bunsen to
> > be compared.
> 
> Great, thanks! I guess the errors are the same as observed on
> gcc-full-debian-arm64?

I assume so, but don't have internet access at the moment to check.
You can use the bunsen results database to compare different builds:
https://builder.sourceware.org/testruns/

> Anyway I don't think any target has a clean 'make check' in GCC :-(
> 
> This will increase the need for a regression-detection mechanism in the
> buildbot, otherwise we'll only have red bullets which people will ignore....

Yes. I am hoping we can use the bunsen results database to check for
regressions. We have the current build number of the builder, so we
should be able to pull the bunsen results of the previous build. Then
we should be able to compare the dejagnu summary.

> > The ubuntu22_04-armhf worker however fails to do a full gcc build:
> > https://builder.sourceware.org/buildbot/#/workers/33
> > 
> > In file included from ../../../gcc/libgcc/../gcc/tsystem.h:87,
> >                   from ../../../gcc/libgcc/libgcc2.c:27:
> > /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
> >     27 | #include <bits/libc-header-start.h>
> >        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
> > 
> > It looks like that happens while building libcc for
> > armv8l-unknown-linux-gnueabihf. Maybe missing devel header files? Or
> > does the build needs to be configured to exclude this target?
> 
> So... I dug a bit and... you need to add --with-float=hard on GCC's
> configure line. For some reason GCC's configure is not able to infer
> that from the trailing 'hf' in the target name. Can you add it for this
> target only or is the configure line shared by all GCC workers?

Currently the configure line is shared by all gcc-full builders. But
that can be changed. As in the attached patch (apologies for my python
skills). I'll push it once I have internet access again.

Cheers,

Mark

[-- Attachment #2: 0001-Add-gcc_full_build_factory_gen-function.patch --]
[-- Type: text/x-diff, Size: 4719 bytes --]

From dc366c58f2f63cc5aa4955f60ba2c337203c05d0 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Wed, 17 Aug 2022 14:58:40 +0200
Subject: [PATCH] Add gcc_full_build_factory_gen function

Call it with extra_configure_arg="--with-float=hard" for the
gcc_full_ubuntu_armhf_builder.
---
 builder/master.cfg | 62 +++++++++++++++++++++++++---------------------
 1 file changed, 34 insertions(+), 28 deletions(-)

diff --git a/builder/master.cfg b/builder/master.cfg
index f945b14..dc51fd0 100644
--- a/builder/master.cfg
+++ b/builder/master.cfg
@@ -2987,31 +2987,36 @@ gcc_debian_amd64_builder = util.BuilderConfig(
         factory=gcc_build_factory)
 c['builders'].append(gcc_debian_amd64_builder)
 
-gcc_full_build_factory = util.BuildFactory()
-gcc_full_build_factory.addStep(gcc_build_git_step)
-gcc_full_build_factory.addStep(gcc_rm_build_step)
-gcc_full_build_configure_step = steps.Configure(
-        workdir='gcc-build',
-        command=['../gcc/configure',],
-        name='configure',
-        haltOnFailure=True)
-gcc_full_build_factory.addStep(gcc_full_build_configure_step)
-gcc_full_build_factory.addStep(steps.Compile(
-        workdir='gcc-build',
-        command=['make', util.Interpolate('-j%(prop:maxcpus)s')],
-        name='make',
-        haltOnFailure=True))
-# We want parallelism to get through this as quickly as possible.
-# Even if that means bunsen gets some parallel/duplicate log files
-gcc_full_build_factory.addStep(steps.Test(
-        workdir='gcc-build',
-        command=['make', 'check', util.Interpolate('-j%(prop:maxcpus)s')],
-        name='make check',
-        haltOnFailure=False, flunkOnFailure=True))
-gcc_full_build_factory.addSteps(bunsen_logfile_upload_cpio_steps(
-        ["*.log", "*.sum"],
-        workdir='gcc-build'))
-gcc_full_build_factory.addStep(gcc_rm_build_step)
+def gcc_full_build_factory_gen(extra_configure_arg=None):
+        gcc_full_build_factory = util.BuildFactory()
+        gcc_full_build_factory.addStep(gcc_build_git_step)
+        gcc_full_build_factory.addStep(gcc_rm_build_step)
+        configure_command = ['../gcc/configure']
+        if extra_configure_arg:
+                configure_command.append(extra_configure_arg)
+        gcc_full_build_configure_step = steps.Configure(
+                workdir='gcc-build',
+                command=configure_command,
+                name='configure',
+                haltOnFailure=True)
+        gcc_full_build_factory.addStep(gcc_full_build_configure_step)
+        gcc_full_build_factory.addStep(steps.Compile(
+                workdir='gcc-build',
+                command=['make', util.Interpolate('-j%(prop:maxcpus)s')],
+                name='make',
+                haltOnFailure=True))
+        # We want parallelism to get through this as quickly as possible.
+        # Even if that means bunsen gets some parallel/duplicate log files
+        gcc_full_build_factory.addStep(steps.Test(
+                workdir='gcc-build',
+                command=['make', 'check', util.Interpolate('-j%(prop:maxcpus)s')],
+                name='make check',
+                haltOnFailure=False, flunkOnFailure=True))
+        gcc_full_build_factory.addSteps(bunsen_logfile_upload_cpio_steps(
+                ["*.log", "*.sum"],
+                workdir='gcc-build'))
+        gcc_full_build_factory.addStep(gcc_rm_build_step)
+        return gcc_full_build_factory
 
 gcc_full_debian_amd64_builder = util.BuilderConfig(
         name="gcc-full-debian-amd64",
@@ -3020,7 +3025,7 @@ gcc_full_debian_amd64_builder = util.BuilderConfig(
                     readContainerFile('debian-stable')},
         workernames=big_vm_workers,
         tags=["gcc-full", "debian", "x86_64"],
-        factory=gcc_full_build_factory)
+        factory=gcc_full_build_factory_gen())
 c['builders'].append(gcc_full_debian_amd64_builder)
 
 gcc_full_ubuntu_armhf_builder = util.BuilderConfig(
@@ -3028,7 +3033,8 @@ gcc_full_ubuntu_armhf_builder = util.BuilderConfig(
         collapseRequests=True,
         workernames=["ubuntu22_04-armhf"],
         tags=["gcc-full", "ubuntu", "armhf"],
-        factory=gcc_full_build_factory)
+        factory=gcc_full_build_factory_gen(
+                extra_configure_arg="--with-float=hard"))
 c['builders'].append(gcc_full_ubuntu_armhf_builder)
 
 gcc_full_ubuntu_arm64_builder = util.BuilderConfig(
@@ -3036,7 +3042,7 @@ gcc_full_ubuntu_arm64_builder = util.BuilderConfig(
         collapseRequests=True,
         workernames=["ubuntu22_04-arm64"],
         tags=["gcc-full", "ubuntu", "arm64"],
-        factory=gcc_full_build_factory)
+        factory=gcc_full_build_factory_gen())
 c['builders'].append(gcc_full_ubuntu_arm64_builder)
 
 
-- 
2.30.2


  parent reply	other threads:[~2022-08-17 13:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11  7:54 Christophe Lyon
2022-08-11 20:39 ` Mark Wielaard
2022-08-12  7:23   ` Christophe Lyon
2022-08-12 16:44     ` Mark Wielaard
2022-08-16 11:54       ` Christophe Lyon
2022-08-17 11:51         ` Christophe Lyon
2022-08-17 13:00         ` Mark Wielaard [this message]
2022-08-17 13:45           ` Christophe Lyon
2022-08-17 20:42             ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YvzmihMu1YjgVS1I@wildebeest.org \
    --to=mark@klomp.org \
    --cc=buildbot@sourceware.org \
    --cc=christophe.lyon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).