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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Jul 3, 2012 at 10:03 AM, Roland McGrath <mcgrathr@google.com> wrote:
> 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.

Patch is welcome.

> 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?
>

It is easier to write run-time tests to test on all native
targets than parsing readelf output on all targets.

-- 
H.J.