From: Luis Machado <firstname.lastname@example.org>
To: Christophe Lyon <email@example.com>,
Mark Wielaard <firstname.lastname@example.org>,
Subject: Re: Arm binutils buildbot workers
Date: Wed, 20 Jul 2022 08:51:30 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 7/20/22 08:32, Christophe Lyon via Binutils wrote:
> On 7/19/22 23:29, Mark Wielaard wrote:
>> Hi Christophe,
>> On Mon, Jul 18, 2022 at 06:39:42PM +0200, Christophe Lyon wrote:
>>> I've just tried to use the configure/make options I found in master.cfg for
>>> configure --enable-gold --enable-shared --enable-targets=all
>>> make all-gas all-ld all-binutils all-gold
>>> make check-gas check-ld check-binutils
>>> which completes on both 32 and 64 bit systems (aarch64 and armhf).
>>> There are some FAILs in the results, though, but no problem with sim. I
>>> think it is a problem with gdb only?
>> OK great. I guess it is not a problem for just building
>> binutils/gas/ld because that doesn't drag in sim. But when building
>> gdb it might also build sim?
>>>> Could it be both? The idea behind to user try branches is that you can
>>>> run the buildbot builders as if doing a "real" build. There are not
>>>> many people using the try branches at the moment, so it isn't really
>>>> that much more work (also the configuration is simply adding an
>>>> identifical builder to the try-scheduler).
>>> Sure. IIUC, it's just a matter of an additional *_try_*_builder entry in
>>> master.cfg, and they can share the same worker?
>> Yes. The try-builder get triggered by a different schedule (one that
>> listens to the git users/hacker/try- branches). But uses the same
>> buildfactory and the same worker as the normal builder.
>> The worker can also be the same as the workers now used for gdb. So
>> you don't need to create new containers unless you want to.
> OK, so for instance, I could re-start the existing containers, giving them more CPUs (say 8), keep ncpus/maxcpus to 4 in the workers definitions, but increase max_builds to 2, so that for instance we can run binutils and gdb jobs on the same worker at the same time?
> Do binutils and gdb cohabit well when it comes to testing them in parallel? I guess it should be the case, but in practice gdb has proven to have many tests with random results :-(
That should work fine. Most of the instability in GDB is due to timeouts/output ordering issues. It shouldn't get worse if you're running binutils tests in parallel.
next prev parent reply other threads:[~2022-07-20 7:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 10:54 Christophe Lyon
2022-07-17 15:09 ` Mark Wielaard
2022-07-18 9:53 ` Richard Earnshaw
2022-07-18 16:39 ` Christophe Lyon
2022-07-19 21:29 ` Mark Wielaard
2022-07-20 7:32 ` Christophe Lyon
2022-07-20 7:51 ` Luis Machado [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-07-11 9:49 Christophe Lyon
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).