This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [testsuite, build] Convert boehm-gc testsuite to DejaGnu (PR boehm-gc/11412)


Hello Rainer,

* Rainer Orth wrote on Wed, Jan 05, 2011 at 07:06:56PM CET:
> I've long maintained that it would be very helpful to convert the
> boehm-gc testsuite to DejaGnu:
> 
> * It enables multilib testing, giving better test coverage.

I don't understand.  Why should the current tests not be run in multilib
setting?  Does toplevel not enter $target/$MULTIDIR/boehm-gc for check?

> * I set DEJATOOL = boehm-gc in testsuite/Makefile.am.  The default is
>   $PACKAGE, which is gc, but it seemed more intuitive to see boehm-gc in
>   mail-report.log, matching the toplevel directory.
> 
>   As usual, the site.exp target needs to be overridden to pass the
>   configure-determined THREADLIBS and EXTRA_TEST_LIBS down to the
>   testsuite.  This is quite messy; it would be far better if automake
>   provided some facility for that.

Can you open an Automake bug (send mail to bug-automake) with the
features a better support from Automake should have?  Thanks.
I'm still very much a DejaGNU newbie.

> * The primary complication of the boehm-gc testsuite is the
>   staticroottest testcase, which depends on a shared library.
>   Currently, libtool is used to build that and I think that's the right
>   decision rather than duplicating all of libtool's knowledge in
>   DejaGnu.
> 
>   Unfortunately, DejaGnu knows nothing about libtool yet, and I'm still
>   struggling with the right way to integrate it.  For the moment (though
>   I fear that wrong, over-complicated) I've chosen to add two additional
>   keywords (ltassemble and ltlink) to match assemble and link, but for
>   .la, .lo files instead.  I'm open for suggestions for better ways to
>   handle this, though.

I'd be happy to try to help if there are libtool questions, but AFAICS
the issue is mostly how to teach dejagnu how to use it?

> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/boehm-gc/testsuite/boehm-gc.lib/lib.exp	Sat Jan 01 23:52:04 2011 +0100

> +    # FIXME: Explain.  Turn into parameter?
> +    set shopt "-version-info 1:2:0 -no-undefined -rpath /nowhere -shared-libgcc"

You need to prefix -shared-libgcc with -Wc, to get it past libtool.
When creating shared libraries, libtool drops most flags that it does
not know about (and that it could do the wrong thing with if passed),
so with -Wc, you're telling it that you know what you're doing.
(And -shared-libgcc actually might not work correctly in all cases,
which is what I mean with "it does not know about a flag").

> +    set shopt "$shopt $gc_lib_conv"

> +    # Remove $bname.*o and .libs/$bname.*o.
> +    # FIXME: Might use libtool --mode=clean $bname.lo, but is this right in

Missing 'rm -f' after --mode=clean.

> +    # cross-compilation scenarios?

Why should it not be?

> +    # What is it?  build, host?
> +    set to_delete [glob -nocomplain $bname.*o]
> +    set to_delete "$to_delete [glob -nocomplain .libs/$bname.*o]"
> +    eval remote_file build delete $to_delete
> +
> +    return lib$bname.la
> +}
> +
> +# FIXME: Comment.
> +proc boehm-gc-lib-dg-runtest { testcases flags extra-flags } {
> +    global runtests
> +
> +    foreach testcase $testcases {
> +	# If we're only testing specific files and this isn't one of them, skip it.
> +	if ![runtest_file_p $runtests $testcase] {
> +	    return
> +	}
> +
> +	# Library source corresponding to test file.
> +	regsub "test\.c$" $testcase "lib.c" lib
> +	verbose "lib: $lib"
> +
> +	# Build support library.
> +	# FIXME: Handle via dg-add-shlib keyword?
> +	# If so, boehm-gc.lib becomes unnecessary.
> +	set shlib [boehm-gc-shlib $lib $flags ${extra-flags}]
> +
> +	# Run testcase, linking with support library.
> +	dg-test $testcase $flags "${extra-flags} $shlib"
> +
> +	# Remove $shlib, .libs/$shlib.*.
> +	# FIXME: Could the removal be done in a more general place?
> +	# Where is the rest of the removal done?

Can't you use 'libtool --mode=clean' here as well?

> +	set to_delete $shlib
> +	set to_delete "$to_delete [glob -nocomplain .libs/[file rootname $shlib].*]"
> +
> +	# FIXME: Doesn't delete .libs/libstaticrootslib.la and
> +	# .libs/libstaticrootslib.so.1, why?
> +	# Bug in remote.exp (standard_file): checks file exists and file
> +	# isfile first!?
> +	eval remote_file build delete $to_delete
> +
> +	# Remove .libs/$execname.
> +	# FIXME: Should go into the framework somewhere, but dg-final
> +	# cannot be used since that is reset every time dg-test runs.
> +	remote_file build delete .libs/[file rootname [file tail $testcase]]
> +    }
> +}
> +
> +dg-init
> +boehm-gc-init
> +
> +global srcdir subdir
> +
> +# Gather list of tests, skipping library source files.
> +set tests [lsort [glob -nocomplain $srcdir/$subdir/*.c]]
> +set tests [prune $tests $srcdir/$subdir/*lib.c]
> +
> +boehm-gc-lib-dg-runtest $tests "-O2" ""
> +dg-finish

Cheers,
Ralf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]