public inbox for
 help / color / mirror / Atom feed
From: Luis Machado <>
To: Christophe Lyon <>,
	Mark Wielaard <>,,
Subject: Re: Arm binutils buildbot workers
Date: Wed, 20 Jul 2022 08:51:30 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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
>>> binutils_factory_target_all:
>>> 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?
> Exactly.
>>>> 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.
> Nice.
>> 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.

  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

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:

* 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).