MIPS configuration patch to enable --with-[arch,endian,abi]

Here is another MIPS configuration patch, this one allows the mips
configuration to handle the --with-endian, --with-arch, and --with-abi
configure options.  Basically instead of having targets set MIPS_ABI_DEFAULT
and MIPS_ISA_DEFAULT directly in tm_defines based on their triplet names
I have them set default_mips_arch and default_mips_abi.  Then, later
in config.gcc, these can be overridden using the values from --with-arch
and --with-abi and after that they are used to set MIPS_ABI_DEFAULT and
MIPS_ISA_DEFAULT in tm_defines.  --with-endian is also handled this way.

While testing these changes I found that building a non-multilib target with
a default ABI other then the (old) 32 ABI was not working. If I built
using '--with-arch=mips64r2 --with-abi=64 --disable-multilib' for example
there was a mismatch in where the glibc configuration/build wanted
to put system libraries and where the GCC build was looking for them.
If MIPS were built as above it would not use the multilib make fragment
(t-linux64) and would look in /lib and /usr/lib for the system libraries.
The glibc configuration on the other hand would always put 64 bit ABI
libraries in /lib64 and /usr/lib64.

So the question is: should /lib and /usr/lib always be for the default GCC
ABI (whatever that may be) or should /lib and /usr/lib always be for the
MIPS (old) 32 ABI (with /lib32 and /usr/lib32 always being for the MIPS N32
ABI and /lib64 and /usr/lib64 always being for the 64 MIPS ABI.  I chose the
latter as it seemed clearer and more consistent and that is why I also
needed to change mips.h to add the overrides of STANDARD_STARTFILE_PREFIX_1
and STANDARD_STARTFILE_PREFIX_2.  These overrides are not needed if building
a multilib GCC because then MULTILIB_OSDIRNAMES in t-linux64 takes care
of everything, but they are needed if building a non-multilib GCC with a
default ABI other than the old 32 bit ABI.

Tested with many builds of mips*-*-linux-gnu targets and various combinations
of --with-arch, --with-abi, --with-endian, --disable-multilib, and
--enable-targets=all.

OK to checkin?

Steve Ellcey



2014-10-31  Steve Ellcey  <sellcey@imgtec.com>

	* config.gcc (mips*-mti-linux*): Remove gnu_ld and gas assignments.
	Set default_mips_arch and default_mips_abi instead of tm_defines.
	(mips*-*-linux*): Set default_mips_arch and default_mips_abi instead
	of tm_defines.
	(mips*-*-*): Check with_endian, with_arch, with_abi.  Set tm_defines.
	* config/mips/mips.h (STANDARD_STARTFILE_PREFIX_1): Set default
	based on MIPS_ABI_DEFAULT.
	(STANDARD_STARTFILE_PREFIX_2): Ditto.

On Fri, 31 Oct 2014, Steve Ellcey  wrote:

> So the question is: should /lib and /usr/lib always be for the default GCC
> ABI (whatever that may be) or should /lib and /usr/lib always be for the
> MIPS (old) 32 ABI (with /lib32 and /usr/lib32 always being for the MIPS N32
> ABI and /lib64 and /usr/lib64 always being for the 64 MIPS ABI.  I chose the
> latter as it seemed clearer and more consistent and that is why I also
> needed to change mips.h to add the overrides of STANDARD_STARTFILE_PREFIX_1
> and STANDARD_STARTFILE_PREFIX_2.  These overrides are not needed if building
> a multilib GCC because then MULTILIB_OSDIRNAMES in t-linux64 takes care
> of everything, but they are needed if building a non-multilib GCC with a
> default ABI other than the old 32 bit ABI.

/lib and /usr/lib should always be for o32.

> +		if test x$with_endian != x; then
> +			default_mips_endian=$with_endian
> +		fi

install.texi currently says --with-endian is only for SH; you'll need to 
update the documentation to say what versions of this option are supported 
for MIPS.  Also, t-linux64 uses

MIPS_EL = $(if $(filter %el, $(firstword $(subst -, ,$(target)))),el)

to determine endianness for Debian multiarch purposes, and I think this 
will need to change when you allow --with-endian to control the 
endianness.

Steve Ellcey  <sellcey@imgtec.com> writes:
> Here is another MIPS configuration patch, this one allows the mips
> configuration to handle the --with-endian, --with-arch, and --with-abi
> configure options.  Basically instead of having targets set
> MIPS_ABI_DEFAULT
> and MIPS_ISA_DEFAULT directly in tm_defines based on their triplet names
> I have them set default_mips_arch and default_mips_abi.  Then, later
> in config.gcc, these can be overridden using the values from --with-arch
> and --with-abi and after that they are used to set MIPS_ABI_DEFAULT and
> MIPS_ISA_DEFAULT in tm_defines.  --with-endian is also handled this way.

I'm not keen on adding support for --with-endian to mips. I believe that
various build systems have become quite dependent on 'mips' meaning big
endian and 'mipsel' being little endian. I'd prefer to remove that part
unless you (or anyone else) can identify a reason why we should support
it.
 
> So the question is: should /lib and /usr/lib always be for the default GCC
> ABI (whatever that may be) or should /lib and /usr/lib always be for the
> MIPS (old) 32 ABI (with /lib32 and /usr/lib32 always being for the MIPS N32
> ABI and /lib64 and /usr/lib64 always being for the 64 MIPS ABI.  I chose
> the
> latter as it seemed clearer and more consistent and that is why I also

Agreed, the OS directories need to have fixed purposes.

This is OK if --with-endian support is removed, otherwise if you see a
need for it then I'd like to see what Catherine thinks.

Thanks,
Matthew