Guido Guenther wrote: > On Wed, Dec 17, 2003 at 01:23:53PM +0100, Thiemo Seufer wrote: > > This won't work well for MIPS. Targets are mips*-*-linux* and > > mips64*-*-linux*, the latter will usually support all three ABIs. > I think the other architectures also configure as e.g. sparc-linux > although their gcc can produce sparc64 binaries. We should probably do > the same. The patches against gcc 3.4 are minimal to achieve this (on my > list after I was able to build c++) and our binutils already handle n32 > and n64.
Then I don't understand the previous comment about differentiating via host/target. [snip] > > It's probably best to use -mabi=n32 on a "MIPS64" system as default, > > with exceptions for libraries, which should provide all three ABI > > variants somehow, and exceptions for (very) large applications, which > > are of little use in a 32 bit address space (and thus need -mabi=64). > Yept. Another solution would be to really split mips into mips > (supporting o32 only) and mips64 (supporting n32 and n64), The transition to n32/n64 systems would be more problematic then, and it won't save us from Multi-ABI anyway. > we'd keep the > later around only for the R3k systems. But I like the full o32/n32/n64 > aproach more. JFTR, the 32 bit only systems aren't necessarily outdated workstations, 32 bit MIPS is quite popular today (Vendors are e.g. AMD and Toshiba). Thiemo
