Re: Should the linker tests notice multilib variations ?

[Nick Clifton <nickc@cygnus.com>]

Hi Ian, Hi Doug,

: Date: 13 Jul 1999 12:02:05 -0400
: From: Ian Lance Taylor <ian@zembu.com>
: 
:    Date: Tue, 13 Jul 1999 11:24:21 +0100
:    From: Nick Clifton <nickc@cygnus.com>
: 
:      I noticed today that the linker testsuite ignores any mutlilib
:      switches set up by the schedule of variants when it is run.  This
:      seems a little strange to me, especially now that the testsuite is 
:      testing compiler initiated features such as selective linking.
: 
: I've never really understood the current DejaGnu.  Does it have any
: documentation yet?

he he he.  Documentation !  No such luck.

: I think this sort of hackery is inevitable.  Unfortunately, while -EB
: and -EL are globally recognized options for the linker, they are not
: for the assembler.  For example, the PowerPC assembler uses -be and
: -le rather than -EB and -EL.  So you need a more clever hack.  Or you
: need to add support for -EB and -EL to the PowerPC assembler, which
: would be OK.  Perhaps we should even make -EB and -EL global options
: for the assembler, and use some new md function to implement them.

It certainly would be helpful if -EL and -EB could be globally
acceptable as options for choosing endian-ness.  (Assuming that the
target supports both endian variations).  I can fix up the ARM
compiler front end, and if Doug wants to fix the assembler that is
great. 

The problem however is more general than that.  If my patch were to be
applied then we would start running into all kinds of problems with
failed links because the switches and library search directories
passed to the linker would not match up with the binaries being
produced by the compiler.

The endian problem is one example of this.  The compiler is passed the
-mbig-endian switch, produces a big-endian object file, and then the
link fails because it uses a linker script which only uses the default
output format which is (say) little endian.

But the problem is not restricted to endianism.  Any multilib option
which has an effect at link time is going to cause problems.  Suppose
for example that a target has two different APIs and multilibs are
provided for both versions.  When the linker tests are run only the
default libraries will be found (because gcc is not being used to
drive the link process), and so there will be link time fails when
binaries for one API are linked with libraries for the other API.

The only way to be sure that correct executables are produced is to
allow gcc to do the linking as well as the compiling, rather than
invoking the linker directly (since gcc may have to translate some
command line in order for the linker to understand them, and it also
has to sort out the paths to the multilib libraries), and to always
use the built in linker script which will support multiple output
formats.  

I am not sure if the first requirement will be a problem.  Currently
the linker testsuite invokes the linker directly, and presumably there
is a good reason for this.

The second requirement is too restrictive however, as the linker 
tests need to be able to use their own scripts.  This is where Ian's
suggestion comes in.

: I don't think BFD provides the information required to switch between
: big and little endian versions of the same format.  I'm not sure what
: the best way to represent that information would be; perhaps simply a
: new field in the bfd_target structure to hold the address of another
: bfd_target which is the same as the current one, but reverse endian.
: Then the linker could check the byteorder field to see whether it
: should try to use the other endianness.

This should work, now all I need is some free time to work on it...

: It's OK with me to check in your patch.

I'll hold off for now - it breaks too many tests.

Cheers
	Nick