Re: libgo multilib issues.

[David Daney <ddaney at caviumnetworks dot com>]

On 01/27/2011 11:49 AM, Rainer Orth wrote:
> Ian Lance Taylor<iant@google.com>  writes:
>
> > I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS
> > target.  If you need a different syscall_linux_${GOARCH} file for
> > different mips64 targets, then I think we're going to need to test some
> > conditional in libgo/Makefile.am to add the file to build.  E.g., look
> > at syscall_filesize_file.
>
> This is the same difference as between sparc and sparc64/sparcv9: while
> all recent SPARC CPUs are capable of executing 64-bit insns, there's
> both a 32-bit ABI (sparc) and a 64-bit one (sparcv9/sparc64).
>
> On MIPS (at least IRIX and obviously Linux/MIPS as well), you have two
> 32-bit ABIs (O32 and N32) and one 64-bit one (N64), on other systems
> there's also O64.

That's right, but for the sake of argument I would say that o64 is 
unimportant as it is not supported by the Linux kernel.


> It again comes down to what GOARCH is supposed to mean: an ABI, or what
> else?

I would say it is only useful to distinguish the various ABIs.  That is 
the only thing any program really sees.

The output of 'uname -m' is an almost completely usless piece of 
information, so I don't think assigning the value of GOARCH to it makes 
much sense.

Since libgo doesn't even currently build under linux-mips*, we could 
change the values of GOARCH generated for mips without causing regressions.

I would suggest:

GOARCH=mips        # o32
GOARCH=mips64n32   # Would you believe n32?
GOARCH=mips64n64   # ...n64


David Daney