Re: [RFA: and RFC:] run_dump_test in ld: extensions and globalityof testsuite functions.

[Hans-Peter Nilsson <hp at bitrange dot com>]

On 12 Jun 2001, Nick Clifton wrote:
> > - The ld tests are run relative from "ld" and stores test files in
> >   "ld/tmpdir".  Gas tests are run relative from "gas/testsuite" and test
> >   files are stored in that directory.  I guess we can add a testdir
> >   argument and pass it to a run_dump_general, but it seems better to make
> >   ld do like gas so they can more easily share common testsuite functions
> >   without tweaks or parameters.  There's the gcc -B-reason to why ld does
> >   that, but I believe the symlink could be in the ld/testsuite objdir,
> >   i.e. "-B./" when tweaked.  Any reason to not do that?
>
> Hmm, what if the target/remote OS does not support symlinks ?

That's another issue.  I guess you can't run parts of the ld
testsuite then.

> Couldn't "-B../" be used instead ?

No, it's for finding gas, and it wouldn't find ld-new anyway,
when looking for ld.  Perhaps I should expand on the "gcc
-B-reason".  I'm lazy, so I'll just copy what I found in
ld/testsuite/config/default.exp hoping it will clarify:
----
# Make a symlink from tmpdir/as to the assembler in the build tree, so
# that we can use a -B option to gcc to force it to use the newly
# built assembler.
if {![file isdirectory tmpdir/gas]} then {
    catch "exec mkdir tmpdir/gas" status
    catch "exec ln -s ../../../gas/as-new tmpdir/gas/as" status
}
set gcc_gas_flag "-B[pwd]/tmpdir/gas/"
----

> > - With the patch below, we'll have e.g. run_dump_test and regexp_diff in
> >   gas/testsuite and another set in ld/testsuite.  They should be one and
> >   the same, in some common place.  The question is, where?  Suggestion:
> >   libiberty/testsuite/lib.
>
> I like the idea of commoning up these functions.  How about
> dejagnu/lib as the repository though ?

We'd need to include the dejagnu directory in binutils then,
or at least dejagnu/lib.  Putting it in libiberty seems better,
as that would allow more programs to use such library functions
without the need to include dejagnu.  Most (all?) toolchain
program packages use libiberty and have a dejagnu-based
testsuite but most don't include dejagnu.  I think there are
other issues to including and changing dejagnu stuff that I'd
like to avoid, like: is the sources.redhat.com dejagnu really
the official one?

> > Ok to commit?
>
> Approved.

Done.  Thanks for reviewing it.

brgds, H-P