[libgo] Improve Solaris 2/SPARC support

In order to improve Go test results on Solaris 2/SPARC, I need the
following patch.

* go-test.exp wasn't updated for the change from sparcv9 to sparc64.
  While I still don't agree with the new name, at least the two should
  be consistent.

* env.go needs to accept sparc and sparc64.

* Just like 32-bit Solaris 2/x86, 32-bit Solaris 2/SPARC needs to use
  the largefile variants of several functions.  I've not introduced a
  new LIBGO_IS_SOLARIS32 conditional for that, but perhaps one should?

With this patch, results are considerably improved, though still not
good:  the rpc and websocket tests hang indefinitely, as reported in PR
go/48242, so one cannot include Go in a default bootstrap.  I'll
investigate those shortly.  Apart from that, many tests fail, cf. PR
go/48243.

I'll have a look at them in the future, but wanted the get the
low-hanging fruit out of the door.

	Rainer


2011-03-24  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	go:
	* go.test/go-test.exp (go-set-goarch): Use sparc64 for 64-bit SPARC.
	* go.test/test/env.go (main): Handle sparc, sparc64.

	libgo:
	* Makefile.am (go_os_dir_file) [LIBGO_IS_SPARC]: Use
	go/os/dir_largefile.go.
	(syscall_filesize_file) [LIBGO_IS_SPARC]: Use
	syscalls/sysfile_largefile.go.
	(syscall_stat_file) [LIBGO_IS_SPARC]: Use
	syscalls/sysfile_stat_largefile.go.
	* Makefile.in: Regenerate.

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> 2011-03-24  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
>
> 	go:
> 	* go.test/go-test.exp (go-set-goarch): Use sparc64 for 64-bit SPARC.

> diff -r de1b3baf021b gcc/testsuite/go.test/go-test.exp
> --- a/gcc/testsuite/go.test/go-test.exp	Thu Mar 24 13:19:30 2011 +0100
> +++ b/gcc/testsuite/go.test/go-test.exp	Thu Mar 24 13:22:43 2011 +0100
> @@ -129,7 +129,7 @@
>  	    if [check_effective_target_ilp32] {
>  		set goarch "sparc"
>  	    } else {
> -		set goarch "sparcv9"
> +		set goarch "sparc64"
>  	    }
>  	}
>  	default {

Thanks, I just committed this patch to mainline.

I'm working on the other ones.

Ian

Ian Lance Taylor <iant@google.com> writes:

> Thanks, I just committed this patch to mainline.
>
> I'm working on the other ones.

Great, thanks.

With

	[libgo] Support Solaris 8/9
	http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01641.html

and now

	[libgo] Account for 32-bit fds_bits on Solaris 2
        http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02213.html

I'm getting there on Solaris, although a couple of PRs still need
investigation.

I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
9/SPARC (not yet filed or investigated), which hangs the whole build (PR
go/48242).  If I get around to it, I'll probably replace gotest by a
dg-based testsuite.

	Rainer

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR
> go/48242).  If I get around to it, I'll probably replace gotest by a
> dg-based testsuite.

Argh, no, I am trying to fight against that as long as possible.  We
should be moving away from DejaGNU, not toward it.

Ian

Ian Lance Taylor <iant@google.com> writes:

> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
>> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
>> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR
>> go/48242).  If I get around to it, I'll probably replace gotest by a
>> dg-based testsuite.
>
> Argh, no, I am trying to fight against that as long as possible.  We
> should be moving away from DejaGNU, not toward it.

Do you have a decent alternative?  I've no idea what happened to QMTest
which CodeSourcery tried for the C++ testsuite.

handwritten shell-scripts like gotest which lack all the basic features
of dg (timeouts, a proper record of which tests ran and their status, ...)
certainly don't cut it for me.  So far the libgo testsuite lacks all of
this, causing trouble without end (at least for me).

I'm certainly not enamored with Tcl, Expect and DejaGnu, but so far they
do a decent job.  Having each library run its testsuite as it pleases
with different output and different ways of dealing with XFAILs,
target-dependent options and stuff, is completely unmaintainable IMO.

	Rainer

Hello,

* Rainer Orth wrote on Thu, Mar 31, 2011 at 06:12:31PM CEST:
> Ian Lance Taylor <iant@google.com> writes:
> > Argh, no, I am trying to fight against that as long as possible.  We
> > should be moving away from DejaGNU, not toward it.
> 
> Do you have a decent alternative?  I've no idea what happened to QMTest
> which CodeSourcery tried for the C++ testsuite.

FWIW, Automake's parallel-tests driver at least provides halfway decent
test results summary; timeouts and remote control would need to be
implemented by means of a per-test driver script or program though.
And of course the summary style is different from the dejagnu one ...

I'm not advocating anything here, but bringing up the topic only because
there's a Google Summer of Code project proposal to add subunit/TAP test
protocol support to Automake[1], and if that makes it a more viable
target for GCC, or if there are things missing that we should maybe
lookout for and try to cater to, then I'm very interested in details
early, while the proposal is still in the planning stage.

Thanks,
Ralf

[1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/slattarini/1

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Ian Lance Taylor <iant@google.com> writes:
>
>> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>>
>>> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
>>> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR
>>> go/48242).  If I get around to it, I'll probably replace gotest by a
>>> dg-based testsuite.
>>
>> Argh, no, I am trying to fight against that as long as possible.  We
>> should be moving away from DejaGNU, not toward it.
>
> Do you have a decent alternative?  I've no idea what happened to QMTest
> which CodeSourcery tried for the C++ testsuite.
>
> handwritten shell-scripts like gotest which lack all the basic features
> of dg (timeouts, a proper record of which tests ran and their status, ...)
> certainly don't cut it for me.  So far the libgo testsuite lacks all of
> this, causing trouble without end (at least for me).
>
> I'm certainly not enamored with Tcl, Expect and DejaGnu, but so far they
> do a decent job.  Having each library run its testsuite as it pleases
> with different output and different ways of dealing with XFAILs,
> target-dependent options and stuff, is completely unmaintainable IMO.

I don't have a decent alternative.  I did just commit code to track test
results in a DejaGNU-like fashion, and I will add test timeouts shortly.

Still, I think we need to move forward, and the way to move forward is
not to move backward.

A testsuite needs a little infrastructure, but it doesn't need very
much.  What is holding us back is not the infrastructure; it's the
knowledge currently baked into DejaGNU about how to build programs for
target boards and run them there.  For native testing we can cobble
things together easily enough.

Ian

On Thu, 31 Mar 2011, Ralf Wildenhues wrote:

> Hello,
> 
> * Rainer Orth wrote on Thu, Mar 31, 2011 at 06:12:31PM CEST:
> > Ian Lance Taylor <iant@google.com> writes:
> > > Argh, no, I am trying to fight against that as long as possible.  We
> > > should be moving away from DejaGNU, not toward it.
> > 
> > Do you have a decent alternative?  I've no idea what happened to QMTest
> > which CodeSourcery tried for the C++ testsuite.
> 
> FWIW, Automake's parallel-tests driver at least provides halfway decent
> test results summary; timeouts and remote control would need to be
> implemented by means of a per-test driver script or program though.
> And of course the summary style is different from the dejagnu one ...

As far as I could see when I last looked at it, Automake's test code lacks 
the basic feature of being able to test installed programs without 
reconfiguring and rebuilding the code.  No-one really uses GCC with long 
series of -B options in a build tree; installed testing is much closer to 
how it's actually used and the aim should be to move towards staged 
installation for build-tree testing: install in a temporary directory 
within the build tree and run programs from there.  The vast bulk of GCC 
users are probably using a version from a distributor who did install in a 
temporary directory at some point in packaging - the case of someone 
wanting to know if a tool is broken before running "make install" to 
replace a previous installation is not the usual one, and "make install" 
itself should just be copying from such a staging directory in the build 
tree.

Basic features for a new test harness for GCC would include, in my view:

* Starting from installed testing as the basic case (run a test-running 
command, such as runtest at present, to run the tests for the tools in the 
PATH), with more complicated commands for build-tree testing meaning 
passing a more complicated configuration file (generated by the build 
process) to the test-running command.  Definitely do not hardcode details 
of build-tree structure in the test tool itself as DejaGnu does.

* Well-defined enumeration of test assertions independent of running the 
tests.  In DejaGnu the test assertions are the things after "PASS:" or 
"FAIL:" - but there can be duplicate names, and the set of names can 
depend on the results of the tests, or on the build directory name, when 
tests or testsuites are buggy; the system should make it inherently 
impossible to have such problems, so that it is always possible to examine 
results and see what tests did not run, for example.  Similarly, test 
assertion names should be as stable as possible to facilitate comparisons 
when the testsuite itself as well as the compilers being testing may have 
changed.

* Structured results so that build commands and output etc. are 
unambiguously associated with a particular test.  (For DejaGnu you need to 
do heuristic processing of .log files.)

* Well-defined interfaces for defining a target board (i.e., how you run 
a test program on the target, get its output, copy inputs to the board, 
etc.), a host board (for testing the tools themselves on a remote host), a 
testsuite.

* Ability to represent expectations for test results just as flexibly as 
the present XFAILs system.  Some test systems seem to be based on a 
presumption that the expected state is no failures at all, and this is not 
realistic for GCC.

On Thu, 31 Mar 2011, Rainer Orth wrote:

> Ian Lance Taylor <iant@google.com> writes:
> 
> > Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
> >
> >> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
> >> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR
> >> go/48242).  If I get around to it, I'll probably replace gotest by a
> >> dg-based testsuite.
> >
> > Argh, no, I am trying to fight against that as long as possible.  We
> > should be moving away from DejaGNU, not toward it.
> 
> Do you have a decent alternative?  I've no idea what happened to QMTest
> which CodeSourcery tried for the C++ testsuite.

QMTest works fine (and LSB uses it for running an old libstdc++ testsuite 
version, though there are lots of things weird about the LSB testsuites).  
<svn://source.codesourcery.com/qmtest/trunk> (and, for the qmtest_gcc code 
emulating an old version of GCC's test harness, 
<svn://source.codesourcery.com/qmtest_gcc/trunk>).  It has structured 
notions of tests, hosts, results, expectations etc., and doesn't hardwire 
loads of knowledge about the details of a GCC build tree.

> I'm certainly not enamored with Tcl, Expect and DejaGnu, but so far they
> do a decent job.  Having each library run its testsuite as it pleases
> with different output and different ways of dealing with XFAILs,
> target-dependent options and stuff, is completely unmaintainable IMO.

Indeed.  And the main thing required for converting to another harness 
would be rewriting the large piles of existing Tcl code that handles all 
the GCC-specific testsuite features (and, quite possibly, the code in 
dg.exp; the emulation would need to be sufficiently compatible) to work 
with the new harness's interfaces.  You need a clear way to convert all 
testsuites.  Note that the amounts of custom Tcl code have grown massively 
since the previous experiments with emulation in QMTest.

On Mar 31, 2011, at 9:05 AM, Ian Lance Taylor wrote:
> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
>> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR
>> go/48242).  If I get around to it, I'll probably replace gotest by a
>> dg-based testsuite.
> 
> Argh, no, I am trying to fight against that as long as possible.  We
> should be moving away from DejaGNU, not toward it.

The way forward is simple.  Create a dejagnu replacement in python (or other suitable language), excise all tcl code in the testcases into driver fragments in the driver area (testsuite/lib), and slowly expand it out from native only to cross to canadian cross and across test suites.  An ambitious person could convert the whole thing en mass I suspect, leaving all the bugs and features in place, and then just incrementally test and expand coverage.  The advantage of doing the whole thing (dejagnu, testsuite/lib/*) all at once would be to increase the odds that there would be enough features implemented to actually support migrating everything to the new system.  The problem is, unless someone has a cool 3-9 man months to donate, half solutions just forever lag behind, and then we wind up with multiple infrastructures, all alike, but all different.  This later state, is, I'd claim, not a place we want to be either.  By migrating to dejagnu, you at least condense down to one infrastructure, which is good.  We put all our eggs into one basket, so that most people don't ever have to write any tcl code or driver code or worry about what a timeout is, or how you get a file from point a to point b.  Most of the time, you just add the one testcase your interested in, and your done.

Now, another strategy would be to have a driver .exp file leap off into python directly and then just call pass for each line with PASS:, fail for each FAIL: and so on.  The advantage, one could start converting a single small area, the only down side, we'd probably wind up with quite a few of the testsuites unconverted, with twice the code, and random missing features for a long time.  :-(

I don't mind moving away from dejagnu, but, unless someone wants to donate a lot of time and code...

On Thu, 31 Mar 2011, Mike Stump wrote:

> On Mar 31, 2011, at 9:05 AM, Ian Lance Taylor wrote:
> > Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
> >> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and
> >> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR
> >> go/48242).  If I get around to it, I'll probably replace gotest by a
> >> dg-based testsuite.
> > 
> > Argh, no, I am trying to fight against that as long as possible.  We
> > should be moving away from DejaGNU, not toward it.
> 
> The way forward is simple.  Create a dejagnu replacement in python (or 
> other suitable language), excise all tcl code in the testcases into 

If you want a replacement in python, QMTest already exists.  It only has a 
little built-in support for running some sorts of DejaGnu testcases, but 
that's a feature, not a bug; relying on bits of DejaGnu such as dg.exp 
that are too closely involved in the details of compiler testing has 
caused plenty of problems when we'd like to modify those bits as part of 
enhancing the GCC testsuite; putting things such as dg test parsing and 
GCC diagnostic parsing directly in the GCC testsuite code is probably 
better than relying on the bits of support present in core QMTest (but you 
can subclass those bits to the extent that they are useful).

> driver fragments in the driver area (testsuite/lib), and slowly expand 
> it out from native only to cross to canadian cross and across test 
> suites.  An ambitious person could convert the whole thing en mass I 

Note that it's possible to use a DejaGnu board file with another test 
harness (via a special testsuite that waits for "compile" and "run" 
commands and wrapper scripts, run by the other test harness, that send 
those commands).  You probably don't get parallelization that way (where 
it would be possible with a native QMTest host class) but the real issue 
is not existing board files (which you can use more or less as well as you 
can use them at present), it's all the Tcl code in the existing 
testsuites.

> we want to be either.  By migrating to dejagnu, you at least condense 
> down to one infrastructure, which is good.  We put all our eggs into one 

Yes.  And migrating those testsuites that still use .x files instead of 
dg.exp to use dg.exp would similarly be good.