* [libgo] Improve Solaris 2/SPARC support
@ 2011-03-24 16:33 Rainer Orth
2011-03-30 21:27 ` Ian Lance Taylor
2011-03-30 22:40 ` Ian Lance Taylor
0 siblings, 2 replies; 12+ messages in thread
From: Rainer Orth @ 2011-03-24 16:33 UTC (permalink / raw)
To: gcc-patches; +Cc: Ian Lance Taylor
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.
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 {
diff -r de1b3baf021b gcc/testsuite/go.test/test/env.go
--- a/gcc/testsuite/go.test/test/env.go Thu Mar 24 13:19:30 2011 +0100
+++ b/gcc/testsuite/go.test/test/env.go Thu Mar 24 13:22:43 2011 +0100
@@ -1,7 +1,7 @@
// [ $GOOS != nacl ] || exit 0 # NaCl runner does not expose environment
// $G $F.go && $L $F.$A && ./$A.out
-// Copyright 2009 The Go Authors. All rights reserved.
+// Copyright 2009, 2011 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
@@ -15,7 +15,8 @@
print("$GOARCH: ", e0.String(), "\n")
os.Exit(1)
}
- if ga != "amd64" && ga != "386" && ga != "arm" {
+ if ga != "386" && ga != "amd64" && ga != "arm" && ga != "sparc" &&
+ ga != "sparc64" {
print("$GOARCH=", ga, "\n")
os.Exit(1)
}
diff -r de1b3baf021b libgo/Makefile.am
--- a/libgo/Makefile.am Thu Mar 24 13:19:30 2011 +0100
+++ b/libgo/Makefile.am Thu Mar 24 13:22:43 2011 +0100
@@ -676,8 +676,12 @@
if LIBGO_IS_386
go_os_dir_file = go/os/dir_largefile.go
else
+if LIBGO_IS_SPARC
+go_os_dir_file = go/os/dir_largefile.go
+else
go_os_dir_file = go/os/dir_regfile.go
endif
+endif
else
if LIBGO_IS_LINUX
go_os_dir_file = go/os/dir_largefile.go
@@ -1188,16 +1192,21 @@
syscall_stat_file = syscalls/sysfile_stat_largefile.go
else # !LIBGO_IS_LINUX
if LIBGO_IS_SOLARIS
-# FIXME: Same for sparc vs. sparc64. Introduce new/additional conditional?
if LIBGO_IS_386
-# Use lseek64 on 386 Solaris.
+# Use lseek64 on 32-bit Solaris/x86.
syscall_filesize_file = syscalls/sysfile_largefile.go
syscall_stat_file = syscalls/sysfile_stat_largefile.go
-else # !LIBGO_IS_LINUX && LIBGO_IS_SOLARIS && !LIBGO_IS_386
-# Use lseek on amd64 Solaris.
+else # !LIBGO_IS_386
+if LIBGO_IS_SPARC
+# Use lseek64 on 32-bit Solaris/SPARC.
+syscall_filesize_file = syscalls/sysfile_largefile.go
+syscall_stat_file = syscalls/sysfile_stat_largefile.go
+else # !LIBGO_IS_386 && !LIBGO_IS_SPARC
+# Use lseek on 64-bit Solaris.
syscall_filesize_file = syscalls/sysfile_regfile.go
syscall_stat_file = syscalls/sysfile_stat_regfile.go
-endif # !LIBGO_IS_386
+endif # !LIBGO_IS_386 && !LIBGO_IS_SPARC
+endif # !LIBGO_IS_SOLARIS
else # !LIBGO_IS_LINUX && !LIBGO_IS_SOLARIS
# Use lseek by default.
syscall_filesize_file = syscalls/sysfile_regfile.go
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-24 16:33 [libgo] Improve Solaris 2/SPARC support Rainer Orth
@ 2011-03-30 21:27 ` Ian Lance Taylor
2011-03-31 15:55 ` Rainer Orth
2011-03-30 22:40 ` Ian Lance Taylor
1 sibling, 1 reply; 12+ messages in thread
From: Ian Lance Taylor @ 2011-03-30 21:27 UTC (permalink / raw)
To: Rainer Orth; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-24 16:33 [libgo] Improve Solaris 2/SPARC support Rainer Orth
2011-03-30 21:27 ` Ian Lance Taylor
@ 2011-03-30 22:40 ` Ian Lance Taylor
1 sibling, 0 replies; 12+ messages in thread
From: Ian Lance Taylor @ 2011-03-30 22:40 UTC (permalink / raw)
To: Rainer Orth; +Cc: gcc-patches, gofrontend-dev
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
> * 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.
I committed this earlier today.
> * env.go needs to accept sparc and sparc64.
I fixed this in a different way.
> * 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?
I just committed this one, as appended.
Thanks for sending them.
Ian
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1497 bytes --]
diff -r 50a941f17e57 libgo/Makefile.am
--- a/libgo/Makefile.am Wed Mar 30 10:36:43 2011 -0700
+++ b/libgo/Makefile.am Wed Mar 30 14:42:46 2011 -0700
@@ -689,8 +689,12 @@
if LIBGO_IS_386
go_os_dir_file = go/os/dir_largefile.go
else
+if LIBGO_IS_SPARC
+go_os_dir_file = go/os/dir_largefile.go
+else
go_os_dir_file = go/os/dir_regfile.go
endif
+endif
else
if LIBGO_IS_LINUX
go_os_dir_file = go/os/dir_largefile.go
@@ -1219,16 +1223,21 @@
syscall_stat_file = syscalls/sysfile_stat_largefile.go
else # !LIBGO_IS_LINUX
if LIBGO_IS_SOLARIS
-# FIXME: Same for sparc vs. sparc64. Introduce new/additional conditional?
if LIBGO_IS_386
-# Use lseek64 on 386 Solaris.
+# Use lseek64 on 32-bit Solaris/x86.
syscall_filesize_file = syscalls/sysfile_largefile.go
syscall_stat_file = syscalls/sysfile_stat_largefile.go
-else # !LIBGO_IS_LINUX && LIBGO_IS_SOLARIS && !LIBGO_IS_386
-# Use lseek on amd64 Solaris.
+else # !LIBGO_IS_386
+if LIBGO_IS_SPARC
+# Use lseek64 on 32-bit Solaris/SPARC.
+syscall_filesize_file = syscalls/sysfile_largefile.go
+syscall_stat_file = syscalls/sysfile_stat_largefile.go
+else # !LIBGO_IS_386 && !LIBGO_IS_SPARC
+# Use lseek on 64-bit Solaris.
syscall_filesize_file = syscalls/sysfile_regfile.go
syscall_stat_file = syscalls/sysfile_stat_regfile.go
-endif # !LIBGO_IS_386
+endif # !LIBGO_IS_386 && !LIBGO_IS_SPARC
+endif # !LIBGO_IS_SOLARIS
else # !LIBGO_IS_LINUX && !LIBGO_IS_SOLARIS
# Use lseek by default.
syscall_filesize_file = syscalls/sysfile_regfile.go
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-30 21:27 ` Ian Lance Taylor
@ 2011-03-31 15:55 ` Rainer Orth
2011-03-31 16:12 ` Ian Lance Taylor
0 siblings, 1 reply; 12+ messages in thread
From: Rainer Orth @ 2011-03-31 15:55 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-patches
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, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 15:55 ` Rainer Orth
@ 2011-03-31 16:12 ` Ian Lance Taylor
2011-03-31 16:22 ` Rainer Orth
2011-03-31 21:12 ` Mike Stump
0 siblings, 2 replies; 12+ messages in thread
From: Ian Lance Taylor @ 2011-03-31 16:12 UTC (permalink / raw)
To: Rainer Orth; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 16:12 ` Ian Lance Taylor
@ 2011-03-31 16:22 ` Rainer Orth
2011-03-31 16:47 ` Ralf Wildenhues
` (2 more replies)
2011-03-31 21:12 ` Mike Stump
1 sibling, 3 replies; 12+ messages in thread
From: Rainer Orth @ 2011-03-31 16:22 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-patches
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
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 16:22 ` Rainer Orth
@ 2011-03-31 16:47 ` Ralf Wildenhues
2011-03-31 17:16 ` Joseph S. Myers
2011-03-31 16:49 ` Ian Lance Taylor
2011-03-31 17:31 ` Joseph S. Myers
2 siblings, 1 reply; 12+ messages in thread
From: Ralf Wildenhues @ 2011-03-31 16:47 UTC (permalink / raw)
To: Rainer Orth; +Cc: Ian Lance Taylor, gcc-patches
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 16:22 ` Rainer Orth
2011-03-31 16:47 ` Ralf Wildenhues
@ 2011-03-31 16:49 ` Ian Lance Taylor
2011-03-31 17:31 ` Joseph S. Myers
2 siblings, 0 replies; 12+ messages in thread
From: Ian Lance Taylor @ 2011-03-31 16:49 UTC (permalink / raw)
To: Rainer Orth; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 16:47 ` Ralf Wildenhues
@ 2011-03-31 17:16 ` Joseph S. Myers
0 siblings, 0 replies; 12+ messages in thread
From: Joseph S. Myers @ 2011-03-31 17:16 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: Rainer Orth, Ian Lance Taylor, gcc-patches
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.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 16:22 ` Rainer Orth
2011-03-31 16:47 ` Ralf Wildenhues
2011-03-31 16:49 ` Ian Lance Taylor
@ 2011-03-31 17:31 ` Joseph S. Myers
2 siblings, 0 replies; 12+ messages in thread
From: Joseph S. Myers @ 2011-03-31 17:31 UTC (permalink / raw)
To: Rainer Orth; +Cc: Ian Lance Taylor, gcc-patches
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.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 16:12 ` Ian Lance Taylor
2011-03-31 16:22 ` Rainer Orth
@ 2011-03-31 21:12 ` Mike Stump
2011-03-31 22:38 ` Joseph S. Myers
1 sibling, 1 reply; 12+ messages in thread
From: Mike Stump @ 2011-03-31 21:12 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Rainer Orth, gcc-patches
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...
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libgo] Improve Solaris 2/SPARC support
2011-03-31 21:12 ` Mike Stump
@ 2011-03-31 22:38 ` Joseph S. Myers
0 siblings, 0 replies; 12+ messages in thread
From: Joseph S. Myers @ 2011-03-31 22:38 UTC (permalink / raw)
To: Mike Stump; +Cc: Ian Lance Taylor, Rainer Orth, gcc-patches
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.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-03-31 22:16 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-24 16:33 [libgo] Improve Solaris 2/SPARC support Rainer Orth
2011-03-30 21:27 ` Ian Lance Taylor
2011-03-31 15:55 ` Rainer Orth
2011-03-31 16:12 ` Ian Lance Taylor
2011-03-31 16:22 ` Rainer Orth
2011-03-31 16:47 ` Ralf Wildenhues
2011-03-31 17:16 ` Joseph S. Myers
2011-03-31 16:49 ` Ian Lance Taylor
2011-03-31 17:31 ` Joseph S. Myers
2011-03-31 21:12 ` Mike Stump
2011-03-31 22:38 ` Joseph S. Myers
2011-03-30 22:40 ` Ian Lance Taylor
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).