This is the mail archive of the binutils@sourceware.cygnus.com 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]

Re: Should the linker tests notice multilib variations ?


   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?

     I have appended a patch below which attempts to add support for the
     multilib switches, but I am not very happy with it.  In particular I
     have had to add some grubby code to detect if the code was compiled 
     with a big endian or little endian switch and so pass on a -EB or
     -EL switch to the linker or assembler.

     I had to do this because for the ARM toolchain at least, the
     compiler does not accept -EB only -mbig-endian, whereas the linker
     only accepts -EB not -mbig-endian.  Normally gcc would invoke the
     linker, and so it would translate a -mbig-endian command line switch
     into a -EB switch.  But in the case of the linker testsuite, the
     compiler and linker are each invoked seperately, and the switches
     passed to the linker do not get the opportunity to be translated by
     gcc. 

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.

     This patch still breaks several of the ld tests for the ARM however,
     because the testsuite uses custom linker scripts which do not
     include a mutliple option OUTPUT_FORMAT directive, so the default
     output format (little endian arm) is used, and this generates an
     error when used to link big endian arm object files.  I am not sure
     how to solve this problem.  Perhaps the linker ought to be more
     clever about selecting an output format if it is told on the command
     line the endianness that the user desires.

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.

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

Ian

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