Steve Ellcey <sell...@mips.com> writes: > On Fri, 2012-09-07 at 07:52 +0100, Richard Sandiford wrote: > >> MIPS_ABI_DEFAULT and MIPS_ISA_DEFAULT are better set in config.gcc. >> That also allows you to handle (say) mipsisa32-mti-linux-gnu vs. >> mipsisa64-mti-linux-gnu. >> >> I think in general we want more specific header files to come after >> less specific ones, so that the more specific ones can override >> whatever they like. E.g. the order for the generic config/ *.hs >> is "elfos.h gnu-user.h linux.h" and the order for the MIPS ones >> is "mips.h gnu-user.h gnu-user64.h linux64.h". linux-common.h >> coming after linux64.h is an odd-one-out really. >> >> Richard > > OK, here is my latest patch. The only thing I am not sure about is that > you asked me to try building with '--with-arch=mips64 --with-float=hard' > to see if it did something sensible. I am not sure what sensible is. I > am building a cross compiler and when I built with these options the GCC > would generate mips64 code by default. But then the build would fail > because that setup did not match the sysroot that I had built with > mips32r2 as the default set of libraries. I don't know if that is > considered sensible or not.
Well, it sounds a bit odd. Specs are applied in the order: OPTION_DEFAULT_SPEC DRIVER_SELF_SPECS SYSROOT_SUFFIX_SPEC so I would have hoped even OPTION_DEFAULT_SPEC -mips64s would cause the right sysroot suffix to be chosen. > +#undef DRIVER_SELF_SPECS > +#define DRIVER_SELF_SPECS \ > + /* Make sure a -mips option is present. This helps us to pick \ > + the right multilib, and also makes the later specs easier > \ > + to write. */ \ > + MIPS_ISA_LEVEL_SPEC, > \ > + \ > + /* Infer the default float setting from -march. */ > \ > + MIPS_ARCH_FLOAT_SPEC, > \ > + \ > + /* Infer the -msynci setting from -march if not explicitly set. */ > \ > + MIPS_ISA_SYNCI_SPEC, > \ > + \ > + /* Use the standard linux specs for everything else. */ \ > + LINUX64_DRIVER_SELF_SPECS Should add BASE_DRIVER_SELF_SPECS too. OK with that change, thanks. And thanks for your patience. Richard
