Re: PR ld/3351 tests vs incomplete C compiler environment

[Roland McGrath <mcgrathr at google dot com>]

On Tue, Jul 3, 2012 at 9:50 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> indirect.exp has 2 parts: link-time tests and run-time tests.
> run-time tests use the outputs from link-time tests.  That is
> why C compiler is used on link-time tests.

It would be nice if these were separated better.  In my situation, it's not
going to try the run-time tests anyway since it's not a native
configuration.  But the link-time tests fail for unexpected reasons
(missing libraries) rather than the ones it's testing for.  It would be
nice if thing were such that the tests for linker behavior could be tested
with pure assemble/link tests first.  Then the "build stuff for the runtime
tests" steps could be allowed to fail and yield only "untested" rather than
"fail"--or indeed, could be skipped entirely for non-native.

I really don't understand why it makes sense to test by running things
anyway.  Then you're testing the dynamic linker and various other pieces of
the run-time environment as much as you're testing the linker.  The
behavior of the linker is expressed fully in the static contents of its
output.  You can test for the important expected parts of that output just
using objdump/readelf/regexp tests, like the vast majority of the existing
linker tests do.  What's wrong with that?


Thanks,
Roland