From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Clifton To: ian@zembu.com, devans@cygnus.com Cc: binutils@sourceware.cygnus.com Subject: Re: Should the linker tests notice multilib variations ? Date: Tue, 13 Jul 1999 10:21:00 -0000 Message-id: <199907131720.SAA19780@pathia.cygnus.co.uk> X-SW-Source: 1999-q3/msg00180.html Hi Ian, Hi Doug, : Date: 13 Jul 1999 12:02:05 -0400 : From: Ian Lance Taylor : : Date: Tue, 13 Jul 1999 11:24:21 +0100 : From: Nick Clifton : : 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