Re: gcc tri-arch support
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
Reply to: