This is the mail archive of the
mailing list for the binutils project.
Re: PR ld/3351 tests vs incomplete C compiler environment
On Tue, Jul 3, 2012 at 10:03 AM, Roland McGrath <firstname.lastname@example.org> wrote:
> On Tue, Jul 3, 2012 at 9:50 AM, H.J. Lu <email@example.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.