From: Luis Machado <luis.machado@arm.com>
To: Mark Wielaard <mark@klomp.org>
Cc: "Frank Ch. Eigler" <fche@elastic.org>,
Overseers mailing list <overseers@sourceware.org>,
binutils@sourceware.org,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Adding binutils to the GNU Toolchain buildbot on sourceware
Date: Tue, 26 Apr 2022 08:01:33 +0100 [thread overview]
Message-ID: <524b04b7-a78c-7aae-4605-b40f61e6830c@arm.com> (raw)
In-Reply-To: <YmbmguMq2Aq+BzAX@wildebeest.org>
Hi Mark,
I see Frank has put together a worker, but I just wanted to reply to
some points.
On 4/25/22 19:20, Mark Wielaard wrote:
> Hi Luis,
>
> On Mon, Apr 25, 2022 at 01:16:44PM +0100, Luis Machado wrote:
>> On 4/25/22 11:43, Frank Ch. Eigler wrote:
>>>> As a general comment, I think we should have a single buildbot entry for the
>>>> whole of binutils-gdb.
>>>
>>> Perhaps!
>>>
>>>> Given changes to bfd and opcodes can affect gdb, why not build gdb alongside
>>>> the other tools? You don't need to run the gdb testsuite, which should make
>>>> things much more deterministic.
>>>
>>> But this is not an argument for building gdb as a part of testing binutils.
>>> This is an argument for building & testing gdb if binutils changes.
>>> That is: an additional buildbot job
>>
>> An additional buildbot job for gdb/gdbserver would be fine. It's just that a
>> single build for everything is simpler, in my opinion.
>>
>> Is the idea to revive the old buildbot we had for GDB, but for binutils?
>
> We could provide some of the builds that the old buildbot did for
> GDB. But the new builder is not GDB specific and I hope we can learn
> from the old gdb buildbot.
>
> The problem with the old gdb buildbot is that it did too much and had
> flaky test results. This caused people to not care, think the reports
> were annoying, broken builds sometimes only got reported after hours or
> even days.
>
> I think we should try to keep builds/checks under 10 minutes, that the
> checks should be for things that the maintainers think should always
> be green. So that you get a report about something important breaking
> within 10 minutes while you still know what you did. Another reason to
> keep build/check times short is so you can test multiple commits per
> hour.
I agree with the quick build idea. That's why I suggested only making
sure gdb/gdbserver/sim builds properly. That's reasonably reliable.
Unfortunately gdb's testsuite is not too reliable. It's been improved
over the years, but still gives quite a bit of non-deterministic results
based on distro version/compiler version etc. So I'd leave those out in
favor of just making sure things build properly.
If this effort can accomodate the gdb/gdbserver/sim builds, that would
be great. I don't mean to broaden the scope of the initial proposed
effort, but I think it is beneficial to make sure everything is building OK.
>
> If there are extra resources then we can also add builders that take
> longer and/or run testsuites on arches/distros that are known
> broken. But those would then probably not sent out reports but you
> would use them to see the current status of some setup that might not
> be 100% green. And that would probably mean adding more
> hardware/workers.
That makes sense, but gdb-wise I think that can wait.
>
> I assume that knowing that gdb and gdbserver still build OK, without
> running any tests might be important to the gdb maintainers. And that
> just a build of gdb and gdbserver will take < 10 minutes on most
> setups.
>
> If so lets just pick one or more of the workers which seem like stable
> distros/arches that should always build gdb:
> https://builder.sourceware.org/buildbot/#/workers
> (don't pick sourceware, which is special, debian-arm64, debian-armhf,
> debian-i386 or fedora-ppc64 which are too slow)
>
> Provide a file list (directories) of files in the binutils-gdb.git
> repo that should trigger a build.
>
> A configure and make line that does a quick build for just
> gdb/gdbserver which should always build.
I think the following will do:
./configure --enable-targets=all; make all-gdb all-gdbserver
or
./configure --enable-targets=all --disable-sim; make all-gdb all-gdbserver
gdbserver, unlike gdb, will only build natively, hence why it would
benefit from being built everywhere.
>
> If the is a make check-something that can be executed quickly, < 5
> minutes runtime, and that should always be green please include
> it. But please exclude anything that takes too long, isn't known
> all-green or contains flaky tests.
Some tests should always work, no matter what. We could hand-pick some
tests from the GDB testsuite that we consider critical. I don't think we
should focus on that at this point though.
>
> And the mailinglist to which to report any failing commits.
> gdb-patches I assume?
gdb-testers should be fine.
>
> Cheers,
>
> Mark
>
next prev parent reply other threads:[~2022-04-26 7:01 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 9:04 Mark Wielaard
2022-04-25 10:37 ` Luis Machado
2022-04-25 10:43 ` Frank Ch. Eigler
2022-04-25 12:16 ` Luis Machado
2022-04-25 12:30 ` Frank Ch. Eigler
2022-04-25 18:20 ` Mark Wielaard
2022-04-25 18:27 ` Frank Ch. Eigler
2022-04-25 22:11 ` Mark Wielaard
2022-04-26 3:33 ` Alan Modra
2022-04-26 6:22 ` Jan Beulich
2022-04-26 12:27 ` Nick Clifton
2022-04-26 13:49 ` Jan Beulich
2022-04-26 15:47 ` H.J. Lu
2022-04-27 6:15 ` Jan Beulich
2022-04-28 12:10 ` Nick Clifton
2022-04-28 13:07 ` Jan Beulich
2022-04-26 15:54 ` H.J. Lu
2022-04-26 23:33 ` Alan Modra
2022-04-27 18:32 ` [PATCH] x86: Disable 2 tests with large memory requirement H.J. Lu
2022-04-26 7:01 ` Luis Machado [this message]
2022-04-26 9:40 ` Adding binutils to the GNU Toolchain buildbot on sourceware Frank Ch. Eigler
2022-04-26 22:59 ` Mark Wielaard
2022-04-26 22:34 ` Mark Wielaard
2022-04-28 12:23 ` Luis Machado
2022-04-28 13:50 ` Frank Ch. Eigler
2022-04-28 13:53 ` Luis Machado
2022-04-28 14:22 ` Frank Ch. Eigler
2022-04-28 17:04 ` Mark Wielaard
2022-04-28 14:48 ` Mark Wielaard
2022-04-28 14:19 ` Mark Wielaard
2022-04-28 14:47 ` Thomas Fitzsimmons
2022-04-28 16:28 ` Mark Wielaard
2022-05-01 16:37 ` binutils builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware) Mark Wielaard
2022-05-05 7:53 ` Jan Beulich
2022-05-07 20:25 ` Mark Wielaard
2022-05-16 9:40 ` Mark Wielaard
2022-04-28 17:50 ` Adding binutils to the GNU Toolchain buildbot on sourceware Nick Alcock
2022-04-29 17:54 ` Mark Wielaard
2022-04-30 0:12 ` Nick Alcock
2022-04-30 22:27 ` Mark Wielaard
2022-05-03 12:48 ` Nick Alcock
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=524b04b7-a78c-7aae-4605-b40f61e6830c@arm.com \
--to=luis.machado@arm.com \
--cc=binutils@sourceware.org \
--cc=fche@elastic.org \
--cc=gdb@sourceware.org \
--cc=mark@klomp.org \
--cc=overseers@sourceware.org \
/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).