Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jan Beulich via Gdb <gdb@sourceware.org>
To: Nick Clifton <nickc@redhat.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
	Overseers mailing list <overseers@sourceware.org>,
	Alan Modra <amodra@gmail.com>,
	"gdb@sourceware.org" <gdb@sourceware.org>,
	Mark Wielaard <mark@klomp.org>,
	"Frank Ch. Eigler" <fche@elastic.org>,
	binutils@sourceware.org
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:50 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 via Gdb
2022-04-25 10:43   ` Frank Ch. Eigler via Gdb
2022-04-25 12:16     ` Luis Machado via Gdb
2022-04-25 12:30       ` Frank Ch. Eigler via Gdb
2022-04-25 18:20       ` Mark Wielaard
2022-04-25 18:27         ` Frank Ch. Eigler via Gdb
2022-04-25 22:11           ` Mark Wielaard
2022-04-26  3:33         ` Alan Modra via Gdb
2022-04-26  6:22           ` Jan Beulich via Gdb
2022-04-26 12:27             ` Nick Clifton via Gdb
2022-04-26 13:49               ` Jan Beulich via Gdb [this message]
2022-04-26 15:47                 ` H.J. Lu via Gdb
2022-04-27  6:15                   ` Jan Beulich via Gdb
2022-04-28 12:10                 ` Nick Clifton via Gdb
2022-04-28 13:07                   ` Jan Beulich via Gdb
2022-04-26 15:54           ` H.J. Lu via Gdb
2022-04-26 23:33             ` Alan Modra via Gdb
2022-04-27 18:32               ` [PATCH] x86: Disable 2 tests with large memory requirement H.J. Lu via Gdb
2022-04-26  7:01         ` Adding binutils to the GNU Toolchain buildbot on sourceware Luis Machado via Gdb
2022-04-26  9:40           ` Frank Ch. Eigler via Gdb
2022-04-26 22:59             ` Mark Wielaard
2022-04-26 22:34           ` Mark Wielaard
2022-04-28 12:23             ` Luis Machado via Gdb
2022-04-28 13:50               ` Frank Ch. Eigler via Gdb
2022-04-28 13:53                 ` Luis Machado via Gdb
2022-04-28 14:22                   ` Frank Ch. Eigler via Gdb
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 via Gdb
2022-05-13  8:21                       ` Mark Wielaard
2022-04-28 17:50               ` Adding binutils to the GNU Toolchain buildbot on sourceware Nick Alcock via Gdb
2022-04-29 17:54                 ` Mark Wielaard
2022-04-30  0:12                   ` Nick Alcock via Gdb
2022-04-30 22:27                     ` Mark Wielaard
2022-05-03 12:48                       ` Nick Alcock via Gdb

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=gdb@sourceware.org \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=fche@elastic.org \
    --cc=hjl.tools@gmail.com \
    --cc=jbeulich@suse.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