On 01/28/15 15:16, Rainer Orth wrote:
Jakub Jelinek <ja...@redhat.com> writes:
On Wed, Jan 28, 2015 at 01:42:47PM -0700, Jeff Law wrote:
2015-01-28 Rainer Orth <r...@cebitec.uni-bielefeld.de>
gcc/testsuite:
* gcc.dg/guality/guality.h (main): Add argv[0] to
guality_gdb_command.
OK.
As for what to do with guality, I haven't a clue. They're dependent on the
debugger version and perhaps other stuff that I don't recall.
Perhaps skip them if we find gdb and determine it is "too old"?
We already do that. I bet the Solaris case is more about the lack
of support to find an executable from its pid (/proc/<pid>/exe
in Linux).
Guess one can easily try it, run
gdb
(without arguments, or those -nx -nw that guality uses) and type
attach 19355 # pick pid of some process you can debug
in Linux gdb will find the binary etc.
That issue is easily solved by passing the executable name to gdb; this
is guaranteed to work everywhere. On Solaris (at least from Solaris 10
onwards, haven't checked earlier version), gdb could use
/proc/<pid>/path/a.out to get at the executable, but that won't help for
released versions of gdb (and eventually other platforms which provide
no such facility).
But this issue is minor and easily avoided. The major problem is that
on both Solaris and Linux, many of the guality tests FAIL (or XPASS,
equally adding noise to mail-reports.log) even with a current version of
gdb (7.8 in my case):
Linux/x86_64 Solaris 11/x86 Solaris 11/SPARC
(Fedora 20)
gcc.dg/guality:
# of expected passes 6490 6500 5489
# of unexpected failures 191 171 802
# of unexpected successes 61 66 73
# of expected failures 35 30 23
# of unsupported tests 257 267 383
g++.dg/guality:
# of expected passes 128 128 118
# of unexpected failures 6 10 10
# of unsupported tests 34 30 40
Could we select a version of gdb as a reference version, then xfail
those tests which don't work with that reference version on each
platform to cut down the noise? Obviously we bump the reference
version, probably as we close stage1 or stage3 development?
It's not unusual to have different test results across x86 vs x86_64 vs
sparc. What I'd be real interested to know is if x86 across linux
and solaris give the same results, similarly for x86-64 across those two
platforms.
I realize it's a fair amount of work, but I'm always reluctant to simply
disable a large number of tests.
Jeff