This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Tue, Jul 3, 2012 at 10:03 AM, Roland McGrath <> wrote:
> On Tue, Jul 3, 2012 at 9:50 AM, H.J. Lu <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]