[MIPS] Cleanup mips header files.

I would like to do some cleanup on the mips configuration code, both to
reduce the amount of duplicated code and to add better support for --with-arch,
--with-endian, and --with-abi.  As the first step in this work I would like
to check in this patch that removes the linux64.h and gnu-user64.h header
files and copies the needed pieces to linux.h and gnu-user.h.

Right now these headers are used when building a mips64* target or if you
use --enable-target=all, but there is no reason they can't be used for normal
32 bit mips targets too.  Then the only thing has to be done differently for
mips64* targets (or --enable-target=all) vs. mips 32 bit targets is to add
the multilib makefile fragment (t-linux64).

Most of the changes here are just moving macros from one file to another.
The only real functional changes are with GNU_USER_TARGET_LINK_SPEC and
LINUX_DRIVER_SELF_SPECS where we pass more explicit options to the linker
and now have a single consistent definition of these macros for all mips
targets instead of different ones for mips32 and mips64.

I built multiple different mips*-*-linux-gnu targets to test this change
but there are a lot of combinations and I couldn't build all of them.

OK for checkin?

Steve Ellcey
sellcey@mips.com



2014-09-26  Steve Ellcey  <sellcey@mips.com>

	* config/mips/linux64.h: Remove.
	* config/mips/gnu-user64.h: Remove.
	* gcc.config (mips*-*-*): Remove references to linux64.h and
	gnu-user64.h
	* config/mips/gnu-user.h (GNU_USER_TARGET_LINK_SPEC): Replace
	with modified version from gnu-user64.h.
	(LINUX_DRIVER_SELF_SPECS): Update parts from gnu-user64.h.
	(LOCAL_LABEL_PREFIX): Copy from gnu-user64.h.
	* config/mips/linux.h (GNU_USER_LINK_EMULATION32): Copy from
	linux64.h.
	(GNU_USER_LINK_EMULATION64): Ditto.
	(GNU_USER_LINK_EMULATIONN32): Ditto.
	(GLIBC_DYNAMIC_LINKER32): Ditto.
	(GLIBC_DYNAMIC_LINKER64): Ditto.
	(GLIBC_DYNAMIC_LINKERN32): Ditto.
	(UCLIBC_DYNAMIC_LINKER32): Ditto.
	(UCLIBC_DYNAMIC_LINKER64): Ditto.
	(UCLIBC_DYNAMIC_LINKERN32): Ditto.
	(BIONIC_DYNAMIC_LINKERN32): Ditto.
	(GNU_USER_DYNAMIC_LINKERN32): Ditto.
	(GLIBC_DYNAMIC_LINKER): Delete.
	(UCLIBC_DYNAMIC_LINKER): Delete.

Hi Steve,

You're the lucky recipient of my first review so apologies for being
slow and cautious...

I tried to find a reason why the files were originally separated like this
and I can't see anything obvious.  I assume you also found no reason.
Presumably the separation was just to avoid disturbing the 32-bit configs
but I think it is a sensible move to merge them.

> --- a/gcc/config/mips/gnu-user.h
> +++ b/gcc/config/mips/gnu-user.h
> @@ -52,16 +52,20 @@ along with GCC; see the file COPYING3.  If not see
>  #undef MIPS_DEFAULT_GVALUE
>  #define MIPS_DEFAULT_GVALUE 0
> 
> -/* Borrowed from sparc/linux.h */
>  #undef GNU_USER_TARGET_LINK_SPEC
> -#define GNU_USER_TARGET_LINK_SPEC \
> - "%(endian_spec) \
> -  %{shared:-shared} \
> +#define GNU_USER_TARGET_LINK_SPEC "\
> +%{G*} %{EB} %{EL} %{!EB:%{!EL:%(endian_spec)}} %{mips*} \
> +%{shared} \

Indent two lines above. The '%{!EB:%{!EL:%(endian_spec)}}' is
redundant as it is covered by the DRIVER_SELF_SPEC which you have added
below. The linker won't accept -mips16 so you should use
MIPS_ISA_LEVEL_OPTION_SPEC to avoid passing mips16. Although we still
end up with an explicit list at least there is just one copy to maintain.

>    %{!shared: \
>      %{!static: \
>        %{rdynamic:-export-dynamic} \
> -      -dynamic-linker " GNU_USER_DYNAMIC_LINKER "} \
> -      %{static:-static}}"
> +      %{mabi=n32: -dynamic-linker " GNU_USER_DYNAMIC_LINKERN32 "} \
> +      %{mabi=64: -dynamic-linker " GNU_USER_DYNAMIC_LINKER64 "} \
> +      %{mabi=32: -dynamic-linker " GNU_USER_DYNAMIC_LINKER32 "}} \
> +    %{static:-static}} \

Very much a nit but if we are going to have %{shared} above then we should
have just %{static} here.

> +%{mabi=n32:-m" GNU_USER_LINK_EMULATIONN32 "} \
> +%{mabi=64:-m" GNU_USER_LINK_EMULATION64 "} \
> +%{mabi=32:-m" GNU_USER_LINK_EMULATION32 "}"
>  #undef LINK_SPEC
>  #define LINK_SPEC GNU_USER_TARGET_LINK_SPEC
> 
> @@ -122,7 +126,9 @@ extern const char *host_detect_local_cpu (int argc,
> const char **argv);
>       specs handling by removing a redundant option.  */			\
>    "%{!mno-shared:%<mplt}",						\
>    /* -mplt likewise has no effect for -mabi=64 without -msym32.  */	\
> -  "%{mabi=64:%{!msym32:%<mplt}}"
> +  "%{mabi=64:%{!msym32:%<mplt}}"					\
> +  " %{!EB:%{!EL:%(endian_spec)}}"					\
> +  " %{!mabi=*: -" MULTILIB_ABI_DEFAULT "}"

Another nit, since this code is being changed can you update this from using
a leading space to be a comma separated list of strings like this:

> +  "%{mabi=64:%{!msym32:%<mplt}}",					\
> +  "%{!EB:%{!EL:%(endian_spec)}}",					\
> +  "%{!mabi=*: -" MULTILIB_ABI_DEFAULT "}"

With those changes can you double check that a default big and default little
endian build pass -EB/-EL respectively by default and are changed when using
-EL/-EB explicitly? There should only be one -E* option passed to the linker
theoretically, unless multiple explicit -E* options are given on the command
line.

Otherwise OK (assuming the link specs behave as described above).

Thanks,
Matthew

On Mon, 2014-10-06 at 14:25 -0700, Matthew Fortune wrote:
> Hi Steve,
> 
> You're the lucky recipient of my first review so apologies for being
> slow and cautious...
> 
> I tried to find a reason why the files were originally separated like this
> and I can't see anything obvious.  I assume you also found no reason.
> Presumably the separation was just to avoid disturbing the 32-bit configs
> but I think it is a sensible move to merge them.

That was also my guess as to why it was done that way.

> With those changes can you double check that a default big and default little
> endian build pass -EB/-EL respectively by default and are changed when using
> -EL/-EB explicitly? There should only be one -E* option passed to the linker
> theoretically, unless multiple explicit -E* options are given on the command
> line.

I made the syntax changes, removed the '%{!EB:%{!EL:%(endian_spec)}}'
part of GNU_USER_TARGET_LINK_SPEC and double checked that we still pass
-EL or -EB to the linker in all cases.

> Otherwise OK (assuming the link specs behave as described above).
> 
> Thanks,
> Matthew

Thanks for the review, I have gone ahead and checked in the patch with
those changes.

Steve Ellcey
sellcey@mips.com