Steve Ellcey <sell...@mips.com> writes: > On Mon, 2012-09-17 at 21:36 +0100, Richard Sandiford wrote: >> It's a hosted vs. embedded thing. Hosted targets like *-linux-gnu have >> dynamic ABI requirements and so are keyed off an ABI rather than an >> architecture. The only effect of -march= and --with-arch= should be to >> extend the choice of available instructions. >> >> That was actually very useful in pre MIPS(isa)32 and MIPS(isa)64 days, >> because MIPS IV had ISA extensions that could be used in 32-bit as well >> as 64-bit code. You could therefore use the MIPS IV extensions with an >> existing 32-bit MIPS I or MIPS II sysroot. The same sort of thing applied >> to processor-specific extensions in 64-bit processors (of which there were >> many :-)). It's less useful with the stock MIPS32 and MIPS64 ISAs because >> the 32-bit subset of MIPS64 is (by design) essentially MIPS32. > > If this is less useful now and since the multilib mips-mti-linux-gnu > target I created earlier is only supporting the mips32(r2) and > mips64(r2) ISAs (and not MIPS IV, etc) what do you think about me > changing that target to default to n32 when specifying the mips64 or > mips64r2 architectures and not specifying an explicit ABI? That way > both the mips-mti-linux-gnu and mips-mti-elf targets will behave in the > same way with regards to the default ABI.
JFTR, it would be the case even if you did support MIPS IV. n32 was the best ABI there too. My point was that if you only had access to a 32-bit sysroot and/or kernel, compiling for o32 with MIPS IV (i.e. a 64-bit arch) did have something to offer over o32 with the "highest" 32-bit arch (MIPS II). But yeah, since mips-mti-linux-gnu provides separate multilibs and sysroots for mips64 and mips64r2, you can define the ABI of those multilibs and sysroots to be what you like. And I agree n32 makes sense. But I think it would be a bad idea simply to add a rule to DRIVER_SELF_SPECS. I think you'd also want to make the 64-bit sysroots "mips64-linux-gnu-style" (i.e. IRIX-6-style) sysroots, with n32 stuff in /lib32, /usr/lib32, etc., rather than in /lib and /usr/lib. That way, your sysroots are compatible with mipsisa64-linux-gnu and mipsisa63r2-linux-gnu, in case anyone ever does need to build their own toolchain. You also won't need to patch glibc for your layout, and won't confuse package build scripts that expect n32 stuff to be in the standard locations. Obviously that'll mean a bit of work in the t-* makefile fragments though. Another thing to watch out for is that mips-sde-elf redefines the n32 ABI so that long double is only 64 bits (i.e. equivalent to double), not the ABI-prescribed 128 bits. I think it'd be better to avoid that change for mips-sti-linux-gnu, for the same reasons as above. Richard
