Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Sep 2019 10:13:55 -0500
From:      Kyle Evans <kevans@freebsd.org>
To:        Enji Cooper <yaneurabeya@gmail.com>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>,  svn-src-head <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r352465 - head/share/mk
Message-ID:  <CACNAnaEyHbBuDGC3gxy=6VFo=Ub21abczpBiGtn0wsq3K%2B37Ww@mail.gmail.com>
In-Reply-To: <E262FF1E-5F82-44B5-9534-0DEA8F29B563@gmail.com>
References:  <201909180158.x8I1wuZu011258@repo.freebsd.org> <0FBC9A62-AE3B-4F27-AABC-06FF45F415F1@gmail.com> <CACNAnaG23b92BjmAMD_Pn1PW4gcYEne6vdaJ9SuOxHU1hbmyvg@mail.gmail.com> <CDB9D8B3-4100-4C52-B414-D6C60FE49846@gmail.com> <81382CF5-A928-48EF-93A9-BBBBA174F4BD@gmail.com> <CACNAnaHCO5mTpPFpODTAYwAR1cPo0F29%2BDWxiF0vLTEZDz3yDA@mail.gmail.com> <E262FF1E-5F82-44B5-9534-0DEA8F29B563@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 18, 2019 at 10:04 AM Enji Cooper <yaneurabeya@gmail.com> wrote:
>
>
> > On Sep 18, 2019, at 07:58, Kyle Evans <kevans@freebsd.org> wrote:
> >
> >> On Wed, Sep 18, 2019 at 9:46 AM Enji Cooper <yaneurabeya@gmail.com> wr=
ote:
> >>
> >>
> >>> On Sep 18, 2019, at 07:33, Enji Cooper <yaneurabeya@gmail.com> wrote:
> >>>
> >>>
> >>>>> On Sep 18, 2019, at 05:40, Kyle Evans <kevans@freebsd.org> wrote:
> >>>>>
> >>>>> On Wed, Sep 18, 2019 at 7:34 AM Enji Cooper <yaneurabeya@gmail.com>=
 wrote:
> >>>>>
> >>>>>
> >>>>>> On Sep 17, 2019, at 18:58, Kyle Evans <kevans@freebsd.org> wrote:
> >>>>>>
> >>>>>> Author: kevans
> >>>>>> Date: Wed Sep 18 01:58:56 2019
> >>>>>> New Revision: 352465
> >>>>>> URL: https://svnweb.freebsd.org/changeset/base/352465
> >>>>>>
> >>>>>> Log:
> >>>>>> googletest: default-disable on all of MIPS for now
> >>>>>>
> >>>>>> Parts of the fusefs tests trigger a bug in current versions of llv=
m: IR
> >>>>>> representation of some routine for the MIPS targets is a function =
with a
> >>>>>> large number of arguments. This then leads the compiler on an hour=
+ long
> >>>>>> goose chase, which is OK if you build the current tree but less-so=
 if you're
> >>>>>> trying external toolchain or doing a universe build involving mips=
 when it
> >>>>>> eventually gets switched over to LLVM.
> >>>>>>
> >>>>>> Better, accurate details can be found in LLVM PR43263.
> >>>>>
> >>>>> Uhhhhh... why not do this in tests/sys/... instead?
> >>>>
> >>>> Because there's still value in being able to easily enable these for
> >>>> building/running the complete set of tests through standard build
> >>>> infrastructure, but it's not worth adding a knob specifically for th=
e
> >>>> fusefs tests. I also prefer the communication of it being an
> >>>> off-by-default option and easily deduced from src.conf(5) that this
> >>>> part of the build is default-disabled on mips/mips.
> >>>
> >>> Let me rephrase things a bit: is googlemock broken for all of mips, o=
r is it just the tests? If the latter, the tests should be blacklisted for =
mips with a justification. If the former, I agree your method of dealing wi=
th the situation is ok, but more investigation needs to be done to see whet=
her or not the port (in general) is broken and mark it broken if need be.
> >>
> >> It looks like the latter case, based on the PR, and it=E2=80=99s a bui=
ld performance issue... Is this impacting CI pipelines?
> >>
> >
> > It is the latter, and I do not want to *blacklist* them because as far
> > as I can tell, the tests aren't necessarily broken. I want to
> > workaround them for default by now.
> >
> >>> The problem with src.opts.mk=E2=80=99s per-architecture options, is t=
hat it can be very heavy handed enabling/disabling features. I=E2=80=99m no=
t sure that everything in there warrants disabling at that level.
> >>
> >> My investigation suggests that the course of action was overly heavy h=
anded. While I=E2=80=99m not asking for a revert, it would be really nice i=
f whole features weren=E2=80=99t disabled, unless there=E2=80=99s an issue =
with the feature.
> >>
> >
> > We do not have a lighter method for dealing with this that I can tell,
> > because as I said above: I do not want to blacklist them or completely
> > kill them off. I still want the option to build and test them, but as
> > I aim to switch mips over to llvm I do not want to subject CI and the
> > rest of the world to an extra 1.5+ hour build time for this during
> > tinderbox runs.
> >
> > Given that it's mips, so already tier-high, and I'm one of few people
> > that care about it (and I only care about it for the time being), I
> > intend to leave it as-is since it's still a default in the rest of the
> > world.
>
> Ok, valid straw man argument: in this particular case, should llvm / c++ =
support be disabled instead, since it=E2=80=99s the real underlying issue? =
I=E2=80=99m guessing (non-ancient) g++ doesn=E2=80=99t have this issue.
>
> Again, disabling a framework because of a single issue in the tests doesn=
=E2=80=99t make sense. Unless you have proof that the build times for all o=
f googletest/googlemock with llvm is an issue, this seems like the wrong re=
mediation to perform.
>
> -Enji
>
> PS A heads up to asomers and myself would have been nice. I don=E2=80=99t=
 like post-commit nitpicking, since the issue could have been discussed/rev=
iewed before commit.

If this was any less than a temporary workaround that will get
reverted in due time, I would sympathize with your argument
completely. I had no intention of wasting your time or asomers' time
with this tier-2 problem that had already been diagnosed as an
LLVM/mips bug.

The unfortunate reality is that no one (including CI) is running tests
on FreeBSD/mips, and no one will feel the fallout of this decision.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEyHbBuDGC3gxy=6VFo=Ub21abczpBiGtn0wsq3K%2B37Ww>