PR ld/3351 tests vs incomplete C compiler environment

PR ld/3351 tests vs incomplete C compiler environment

[Roland McGrath]

The new tests you added make the ld testsuite depend on being able to
compile and link C programs.  Heretofore I've been happily running the
testsuite in my situation where there is a partly-working C compiler for
the target, but not enough of an environment for it to link successfully
(missing libraries and such).

Is it possible to reformulate these tests so that they rely only on the
tools in binutils itself, as is the case with most of the tests?

If using the C compiler is really necessary, then that is not so bad by
itself.  But trying to use the compiler driver to link, and thus relying on
target libraries being present (and complete) is a big burden.


Thanks,
Roland

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

[H.J. Lu]

On Tue, Jul 3, 2012 at 9:42 AM, Roland McGrath <mcgrathr@google.com> wrote:
> The new tests you added make the ld testsuite depend on being able to
> compile and link C programs.  Heretofore I've been happily running the
> testsuite in my situation where there is a partly-working C compiler for
> the target, but not enough of an environment for it to link successfully
> (missing libraries and such).
>
> Is it possible to reformulate these tests so that they rely only on the
> tools in binutils itself, as is the case with most of the tests?
>
> If using the C compiler is really necessary, then that is not so bad by
> itself.  But trying to use the compiler driver to link, and thus relying on
> target libraries being present (and complete) is a big burden.
>

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.

-- 
H.J.

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

[Roland McGrath]

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

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

[H.J. Lu]

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.