Testsuite suggestions
Robert Lipe
robertlipe@usa.net
Wed Mar 22 20:14:00 GMT 2000
> Assumption:
> Extending the testsuite to step through compatible architectural
> subvarients will usefully improve coverage.
> ie i686 => i586 => i486 => i386
> alphaev6 => alpha
> hppa2.0 => hppa1.1 => hppa1.0
I've done this in days past. Admittedly, it's been a while but I think
the secret invocation looked something like:
make check-g77 \
RUNTESTFLAGS="--target_board 'unix{-mi386,-mi486,-mi586,-mi686}'"
Substitute whatever combination of "pentiumpro" vs "i686" or "-mblah" vs
"-march" or "-mcpu" is in vogue these days.
> =>
> Dejagnu configuration changes? Complications for OSes where there is a
> minimum assumed varient (Unixware7 assumes i586 for example).
Well, that's just lameness in config.guess. Since the UnixWare box
recommends pentium or faster hardware and someone got tired of trying to
work out the /usr/local/* mess for different config.guess values, that
target was handicapped to default to "i586-...". It's been on my list
to fix for a while...
There's certainly no reason that GCC for UW can't or won't generate 386
code.
> Subject to licensing, Unixware 7, Solaris x86 and FreeBSD
> compilers could be bootstrapped & tested on linux, using respective
> header files, assemblers and linkers etc.
For someone interested in tackling this, I can provide SCO licenses.
The kinds of binaries being run in the testsuite are simple enough
that all the x86 unix mutants will probably run each other. (It's not
exactly like the testsuite is filled with mmap64 or lseek64 calls.)
> Assuming binutils adequately supports dwarf2, a linux dwarf2 build
> could cover similar ground (at least for Unixware 7).
I do this frequently when reporting dwarf problems on the ground that
the people most likely to be able to fix the problems have a Linux box
and if I can confirm that the problem shows up in a Linux/x86 target
that's configured.
> A linux hosted dwarf2 environment, however accomplished should reduce
> developer time supporting dwarf2.
This (and my past life where I wanted to kill stabs in an embedded mips
environment) is why the '--with-dwarf2' configuration flag exists. :-)
I use '-gdwarf-2' for individual tests and try to keep a tree laying
around somewhere that's configured with that as a default.
RJL
More information about the Gcc
mailing list