public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Nick Clifton <nickc@redhat.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
	Overseers mailing list <overseers@sourceware.org>,
	Mark Wielaard <mark@klomp.org>,
	binutils@sourceware.org, "Frank Ch. Eigler" <fche@elastic.org>,
	Alan Modra <amodra@gmail.com>, "H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: Adding binutils to the GNU Toolchain buildbot on sourceware
Date: Tue, 26 Apr 2022 15:49:01 +0200	[thread overview]
Message-ID: <70dc898e-0bc8-5a12-9be7-ac9ffc4e1a26@suse.com> (raw)
In-Reply-To: <7acf388f-eb94-ea28-a9e0-0714310121c0@redhat.com>

On 26.04.2022 14:27, Nick Clifton wrote:
>> For gas/testsuite/gas/i386/rept I did already suggest [1] to simply purge
>> the test as unreliable. I also put under question the purpose that it was
>> originally added for.
>>
>> [1] https://sourceware.org/pipermail/binutils/2022-April/120339.html
> 
> Hmm, I seem to have missed this one.  In fact the entire patch series.  Sorry.
> The series looks good to me, so please go ahead and apply it in its entirety

No problem. With my new powers I had committed it already.

> As for disabling the rept because it is so memory expensive: I think that we
> used to.have an environment variable called something like RUN_EXPENSIVE_TESTS
> that had to be set before certain tests were run.  Checking the sources though
> I cannot find it, so maybe I am imagining things.  I still might be a good idea
> though.  If we use it consistently in the binutils testsuites for the big tests
> then users will probably appreciate the facility.

But a test which is run by almost nobody is more likely to break. Also I
think "expensive" has multiple dimensions (memory and time at least), and
depending on the system one may want to run (or suppress) one but not the
other kind. For the test in question, it is both memory and cycles hungry,
so there the distinction may not matter.

But I'd like to raise the question again: Is what the test was added for
actually a useful thing to test, at the risk of the test failing simply
because there's too little memory available? Iirc the problem was non-
graceful error handling. But the test does not check that the error in
question now is handled gracefully; it expects that there be no error.

Jan


  reply	other threads:[~2022-04-26 13:49 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YmZkKRO+yUHeFqV0@wildebeest.org>
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 [this message]
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         ` Adding binutils to the GNU Toolchain buildbot on sourceware Luis Machado
2022-04-26  9:40           ` 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-04-29 20:04                     ` gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware) Mark Wielaard
2022-05-01 19:44                       ` Mark Wielaard
2022-05-03 15:41                         ` Simon Marchi
2022-05-13  8:21                       ` 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=70dc898e-0bc8-5a12-9be7-ac9ffc4e1a26@suse.com \
    --to=jbeulich@suse.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=fche@elastic.org \
    --cc=gdb@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=mark@klomp.org \
    --cc=nickc@redhat.com \
    --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).