Stuart Anderson wrote: > On Fri, 4 Nov 2005, Thiemo Seufer wrote: > > >We should probably have an consistent naming scheme for o32/n32/n64, and > >avoid _both_ mips32 and mips64 because they are already overloaded in > >their meaning (I would expect a package with -mips32 to be a version > >optimized for MIPS32 ISA). The names "mipsn32" and "mipsn64" may look > >a bit funny, but at least it's clear what they stand for. > > Good point. Which would be better? -mipsn32/-mipsn64 or just -n32/-n64 > as Guido suggested? I don't think the pattern used on other archs helps > us much on this.
-n32/-n64 are already used as toolchain options, -mipsn32/-mipsn64 are unused yet. The Great Plan[TM] I have in mind for further mips improvements is to start a complete port for n32, and a partial port for n64, those would use mipsn32/mipsn32el/mipsn64/mipsn64el as designation. This is a rather long-term plan which requires multiarch support (co-installability of non-executables from different Debian architectures) which is currently in development. Otherwise a partial port doesn't work well, and providing a complete n64 port makes not much sense because most programs don't use that large address spaces and will only be bigger and slower when compared to n32 pendants. Short-term a tri-arch solution on top of the existing o32 port is a good approach to provide 64bit features for selected programs. WRT to naming the ports, the point is that (n)32/(n)64 as well as mips32/mips64 are often already taken to mean something different, e.g. the toolchain uses mips64*-linux for a toolchain which defaults to n32 ABI. For a multiarch solution, we could e.g. introduce mipsn32*-linux and mipsn64-linux configurations without breaking the traditional versions. I think it is valuable to keep the names of tri-arch and multiarch in sync, the less potential confusion the better. > >Not NPTL instead of linuxthreads? > > I was under the impression that NPTL is not quite ready for mips. Also, > it looks like the current package is using linuxthread, so I wanted to > match that. The Kernel starts to support NPTL with IIRC 2.6.11. Since gcc-4.1 NPTL support is integrated in the toolchain. For gcc-4.0 and gcc-3.4 there are backports which aren't yet in the Debian toolchain. Current mips/unstable glibc is probably the last which doesn't support NPTL yet, AFAIK libc >= 2.3.6 will require NPTL support to build. I can see linuxthreads is still the easy way out ATM, but it already is a maintenance millstone, and many architectures already left it. > >The canonical way to select the ABI for a mips compiler is via -mabi=. > >-32/-64 stem from the IRIX compiler, and are only left for backward > >compatibility. > > I added this because I ran into something that was trying to use -32/-64 > in a configure type script. Which is precisely why I recommend against using it. Those scripts often assume -(m)32 to mean ILP32 with 32bit register width, and -(m)64 to mean ILP64 with 64bit register width. Mips will need extra consideration in those cases for proper o32/n32/n64 handling. > >>+# DP: Fix up the directory names so that o32 is the default and the > >>+# DP: 32 & 64 bit names follow the same convention as is used by glibc > > > >Be aware that this is somewhat broken. A mips64-linux compiler has > >different predefined macros than a mips-linux compiler when compiling > >for the same ABI. I have a patch for this and hope to bring it upstream > >in the next weeks. > > Will this affect what the directory names should be? No, it was just meant as a general heads-up triggered by the linux64.h inclusion. Also, glibc is probably not the best thing to follow, it is notoriously undermaintained for mips when compared to the toolchain. > >>-f95_no_cpus := > >>+f95_no_cpus := mips mipsel > > >>-ada_no_cpus := alpha arm armeb m68k sh3 sh3eb sh4 sh4eb > >>+ada_no_cpus := alpha arm armeb m68k sh3 sh3eb sh4 sh4eb mips mipsel > > > >Does this generally lose Ada and Fortran support for mips/mipsel? > > If left like this it would. 8-) I can take this part out. It is left > over from where I was trying to just build the base parts while working out > the details. I left them out as I didn't know of a good way to validate > that they were working correctly. I guess we can assume they do work, > until proven otherwise. Well, they work quite well in unstable ATM. For n32/n64 this might be different, of course. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
