This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gotools] Fix some gotools testing problems
- From: "Ian Lance Taylor via gcc-patches" <gcc-patches at gcc dot gnu dot org>
- To: Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 18 Sep 2017 14:24:56 -0700
- Subject: Re: [gotools] Fix some gotools testing problems
- Authentication-results: sourceware.org; auth=none
- References: <yddo9qgrr6t.fsf@CeBiTec.Uni-Bielefeld.DE>
- Reply-to: Ian Lance Taylor <iant at google dot com>
On Tue, Sep 12, 2017 at 6:18 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
>
> A couple of gotools test FAIL on Solaris, and there are several issues
> that make investigation particularly tedious.
>
> * The one invocation of gotest doesn't support passing additional flags
> (--keep in particular). Added below.
>
> * The order of some of the summaries isn't stable (cmd/go and runtime,
> while cgo and carchive are, it seems). I'm now sorting the output by
> test name, both for make check output and the creation of gotools.sum.
>
> Otherwise, it's hard to compare mail-report.log between builds.
>
> * The freshly built go, cgo, and gofmt rely on LD_LIBRARY_PATH to be set
> so libgcc.so is found at runtime. The right value is passed in from
> the toplevel during a bootstrap, but missing when I run make check in
> gotools manually.
>
> * The most glaring problem is getting your hands on the failing
> executables: there are several levels of indirection here
>
> make -> gotest ... -> go build -> gccgo -> a.out
> -> go test
>
> Many of those steps also depend on lots of environment variables set
> to the check-gcc or check-gccgo wrapper scripts and it's hard to
> determine what's necessary to be able to lay my hand on the resulting
> executable to run it under gdb. I've found no way to pass e.g. -work
> to go build from the outside (e.g. via an environment variable), nor
> can I see the commands executed, so this means modifying the test
> sources or run the full testsuite under truss in the hope to determine
> all that's necessary to reproduce the build.
>
> Anyway, here's the trivial part so far. Ok for mainline?
>
> Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2017-09-12 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
>
> * Makefile.am (GOTESTFLAGS): New variable.
> (check-runtime): Pass it to gotest.
> (check-go-tools): Sort summary.
> (check-runtime): Likewise.
> (check-cgo-test): Likewise.
> (check-carchive-test): Likewise.
> (check): Likewise.
> * Makefile.in: Regenerate.
This patch is OK. Go ahead and commit. Thanks.
What I do for debugging is to run `make install`. Then I can simply
run `GO_TESTING_GOTOOLS=yes go test` in the appropriate directory. I
don't have a good solution for simpler debugging without running `make
install` first.
Ian