Go support in MIPS platform

[Ganbold Tsagaankhuu]

Hi,

Is there any plan to officially support Go in MIPS platform???

The reason I'm asking is because lots of small routers and networking equipments are using MIPS and it would be nice to run networking software written in Go on those MIPS platforms.

thanks a lot,

Ganbold

[Ian Lance Taylor]

The gccgo compiler already supports MIPS.

I don't know of any plans to port the gc compiler to MIPS.

Ian

[andrewc...@gmail.com]

gccgo 5.1 for mips has been notoriously hard to build for me on redhat. I also don't know if that issue regarding closure support was solved?

[Ian Lance Taylor]

On Tue, May 19, 2015 at 3:20 PM, <andrewc...@gmail.com> wrote:
> gccgo 5.1 for mips has been notoriously hard to build for me on redhat. I
> also don't know if that issue regarding closure support was solved?

That's true, I forgot about that: to use current versions of gccgo on
MIPS somebody would have to implement FFI_GO_CLOSURES in the libffi
library. This should not be hard for somebody familiar with MIPS
assembly.

Ian

> On Wednesday, May 20, 2015 at 2:14:58 AM UTC+12, Ian Lance Taylor wrote:
>>
>> On Mon, May 18, 2015 at 8:35 PM, Ganbold Tsagaankhuu <gan...@gmail.com>
>> wrote:
>> >
>> > Is there any plan to officially support Go in MIPS platform???
>> >
>> > The reason I'm asking is because lots of small routers and networking
>> > equipments are using MIPS and it would be nice to run networking
>> > software
>> > written in Go on those MIPS platforms.
>>
>> The gccgo compiler already supports MIPS.
>>
>> I don't know of any plans to port the gc compiler to MIPS.
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[andrewc...@gmail.com]

To avoid the pain of cross compiling I might check if gccgo 5.1 works on one of these images https://people.debian.org/~aurel32/qemu/mips/ . Might take a few days to compile. My real hardware only has 512 megs of ram, which iirc is not enough.

[Ganbold Tsagaankhuu]

On Wed, May 20, 2015 at 9:50 AM, <andrewc...@gmail.com> wrote:

To avoid the pain of cross compiling I might check if gccgo 5.1 works on one of these images https://people.debian.org/~aurel32/qemu/mips/ . Might take a few days to compile. My real hardware only has 512 megs of ram, which iirc is not enough.

Yeah, unfortunately I have MIPS hardware that has only 256MB RAM, and yet gcc5.1 is not in FreeBSD ports.

Ganbold

[andrewc...@gmail.com]

qemu-mips will apparently take weeks to build, so scratch that ;) . I am making a script to make this easy for people to get started with gccgo cross compiling.

https://github.com/andrewchambers/cross-gccgo

@Ian The script does not currently work because of the following error:
...
/go/cmd/go/version.go ../../gcc-5.1.0/gotools/../libgo/go/cmd/go/vet.go ../mipsel-linux/libgo/zstdpkglist.go zdefaultcc.go 
/home/andrewc/Desktop/mips/cross/output/mipsel-linux/bin/ld: cannot find crt1.o: No such file or directory
/home/andrewc/Desktop/mips/cross/output/mipsel-linux/bin/ld: cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status


It is probably something obvious because crt1.o and crti.o do exist, I'm not really sure why ld can't find them, the toolchain seems to be able to build C executables if go is removed from the enabled languages.

[andrewc...@gmail.com]

Manually copying the files into build-gcc/gotools/ solves this problem. But I didn't realize the gccgo go tool does not seem to support the --target option.

[Ian Lance Taylor]

It may be missing some necessary -B options during the build itself.
crt1.o and crti.o are not part of GCC, you must be getting them from
your C library.

Are you using the --with-build-sysroot option when you run configure?
I don't know if that would be enough, but it's probably necessary.

Ian

[Ian Lance Taylor]

On Wed, May 20, 2015 at 5:43 PM, <andrewc...@gmail.com> wrote:
> Manually copying the files into build-gcc/gotools/ solves this problem. But
> I didn't realize the gccgo go tool does not seem to support the --target
> option.

I'm not sure what you mean here--the gc version of the go tool doesn't
have a --target option either.

The gccgo version of the go tool ought to default to running the
installed version of gccgo that it was built with.

Ian

> On Thursday, May 21, 2015 at 12:21:31 PM UTC+12, andrewc...@gmail.com wrote:
>>
>> qemu-mips will apparently take weeks to build, so scratch that ;) . I am
>> making a script to make this easy for people to get started with gccgo cross
>> compiling.
>>
>> https://github.com/andrewchambers/cross-gccgo
>>
>> @Ian The script does not currently work because of the following error:
>> ...
>> /go/cmd/go/version.go ../../gcc-5.1.0/gotools/../libgo/go/cmd/go/vet.go
>> ../mipsel-linux/libgo/zstdpkglist.go zdefaultcc.go
>> /home/andrewc/Desktop/mips/cross/output/mipsel-linux/bin/ld: cannot find
>> crt1.o: No such file or directory
>> /home/andrewc/Desktop/mips/cross/output/mipsel-linux/bin/ld: cannot find
>> crti.o: No such file or directory
>> collect2: error: ld returned 1 exit status
>>
>>
>> It is probably something obvious because crt1.o and crti.o do exist, I'm
>> not really sure why ld can't find them, the toolchain seems to be able to
>> build C executables if go is removed from the enabled languages.
>>
>>
>>

[andrewc...@gmail.com]

Sorry, Its just I am on an x86_64 host but I get this:

[andrewc@mknwsdev30 cross]$ file output/bin/mipsel-linux-go
output/bin/mipsel-linux-go: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped
[andrewc@mknwsdev30 cross]$ file output/bin/mipsel-linux-gccgo
output/bin/mipsel-linux-gccgo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[andrewc@mknwsdev30 cross]$

It doesn't make sense that the go tool is a mips binary, that would partially explain why the crt files are messed up.

[Ian Lance Taylor]

On Wed, May 20, 2015 at 6:05 PM, <andrewc...@gmail.com> wrote:
>
> Sorry, Its just I am on an x86_64 host but I get this:
>
> [andrewc@mknwsdev30 cross]$ file output/bin/mipsel-linux-go
> output/bin/mipsel-linux-go: ELF 32-bit LSB executable, MIPS, MIPS-I version
> 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, with
> unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 =
> 0x1040000, not stripped
> [andrewc@mknwsdev30 cross]$ file output/bin/mipsel-linux-gccgo
> output/bin/mipsel-linux-gccgo: ELF 64-bit LSB executable, x86-64, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
> [andrewc@mknwsdev30 cross]$
>
> It doesn't make sense that the go tool is a mips binary, that would
> partially explain why the crt files are messed up.

Ah, yes, the go tool is built using the newly built gccgo. So if you
are building a cross-gccgo, you will get a go tool built for the
target sytem.

You should build a native gccgo to get a native go tool, and then set
the GOARCH and GCCGO environment variables to run the cross-compiler.

Ian

[andrewc...@gmail.com]

Hmm, my makefile has:

# Use the compiler we just built.
GOCOMPILER = $(GOC_FOR_TARGET)

But from this https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gotools/Makefile.am#L31
It looks like it shouldn't. Will investigate more.

[andrewc...@gmail.com]

Ah, yes, the go tool is built using the newly built gccgo.  So if you
are building a cross-gccgo, you will get a go tool built for the
target sytem.

 

Perhaps this can be fixed so it checks if build != target and if so then require a working build gccgo. It is pretty counter intuitive at the moment. Is that sort of change something that could be accepted? I think that would support canadian cross compilers too...

I assume a build gccgo is not built automatically is that it would require some hacks and doubles the build time.

[andrewc...@gmail.com]

Ok, I think I found a bug in the build scripts.

This check is wrong imo.
https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gotools/configure.ac#L49

This doesn't currently make sense, NATIVE is always true. We aren't cross compiling the compiler itself.
https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gotools/Makefile.am#L31

And I think we should implement this:
https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gotools/Makefile.am#L128

Should I make a thread on golang-dev for this? I think we could make cross compiling using gccgo pretty nice which means people will use gccgo for most embedded things.
With this I can get gccgo added to crosstool-ng, openwrt and buildroot I think.

[andrewc...@gmail.com]

Ok, Just confirming this, I will work on a patch that makes cross compiling work, and make the GOARCH default to whatever gcc was built for.

[Geert-Johan Riemer]

I added gccgo to the OpenWRT build system.
https://github.com/GeertJohan/openwrt-go

[Aram Hăvărneanu]

On Tue, May 19, 2015 at 4:14 PM, Ian Lance Taylor <ia...@golang.org> wrote:
> I don't know of any plans to port the gc compiler to MIPS.

I have some plans, but they are pretty far along the pipeline. Unlikely for 1.6.

--
Aram Hăvărneanu

[Ganbold Tsagaankhuu]

On Thu, May 21, 2015 at 12:03 PM, <andrewc...@gmail.com> wrote:

Ok, Just confirming this, I will work on a patch that makes cross compiling work, and make the GOARCH default to whatever gcc was built for.

Nice. So if gcc 5.x can be cross compiled for mips then for now maybe it is better for me just to try to cross compile gcc on Linux and then try to compile Go program for mips platform.

Ganbold

 

On Thursday, May 21, 2015 at 2:21:57 PM UTC+12, andrewc...@gmail.com wrote:

Ok, I think I found a bug in the build scripts.

This check is wrong imo.
https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gotools/configure.ac#L49

This doesn't currently make sense, NATIVE is always true. We aren't cross compiling the compiler itself.
https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gotools/Makefile.am#L31

And I think we should implement this:
https://github.com/gcc-mirror/gcc/blob/gcc-5_1_0-release/gotools/Makefile.am#L128

Should I make a thread on golang-dev for this? I think we could make cross compiling using gccgo pretty nice which means people will use gccgo for most embedded things.
With this I can get gccgo added to crosstool-ng, openwrt and buildroot I think.

--

[andrewc...@gmail.com]

Did you use 5.1 and the bundled go tool? 

[andrewc...@gmail.com]

Yes, crosscompiling to mips with gccgo has worked for a while. There are issues with cross compiling and the bundled go tool. If you know how, you can work around it.

[Ganbold Tsagaankhuu]

On Thu, May 21, 2015 at 3:52 PM, <andrewc...@gmail.com> wrote:

Did you use 5.1 and the bundled go tool? 

Not yet, I may need to prepare Linux VM and try if time allows.

Ganbold

 

[Ian Lance Taylor]

On Wed, May 20, 2015 at 7:21 PM, <andrewc...@gmail.com> wrote:
>
> Should I make a thread on golang-dev for this? I think we could make cross
> compiling using gccgo pretty nice which means people will use gccgo for most
> embedded things.
> With this I can get gccgo added to crosstool-ng, openwrt and buildroot I
> think.

Sounds good.

The mailing list for development of gccgo itself, apart from gc and
GCC, is gofront...@googlegroups.com.

Ian

[Steve Phillips]

> Yes, crosscompiling to mips with gccgo has worked for a while.

I'm having trouble getting this to work.  I got gccgo-mips-linux-gnu to produce binaries, but the target machine doesn't have the right shared libraries to run them; I get "can't load library 'libm.so.6'" when trying to execute the built binary (here's that thread).

In another thread I saw Dave Cheney tell people to cp -r $GOROOT to another place (call it ~/xgo), touch all the files in ~/xgo/src, make sure GOROOT isn't set, then run the following:

    $ go build -o xgo -compiler gccgo -x cmd/go

This isn't producing a xgo binary at all.  Also, running

    $ GOOS=linux GOARCH=mips go build -o xgo -compiler gccgo -x cmd/go

also generates no xgo binary.

Third attempt: https://github.com/golang/go/wiki/GccgoCrossCompilation makes it sounds like I should use crosstool-ng to build a version of GCC for my target architecture (mips), but can't I just use gccgo-mips-linux-gnu somehow?

Some of these instructions are from 2 years ago, so at this point I don't know what will work now, in 2017.

Any help would be great!  Thanks.

--Steve

[Steve Phillips]

I should add that my target device's kernel doesn't have FPU (floating point) emulation, nor does it have a hardware FPU, and I therefore can't just use go1.8r3's easy-to-use mips support; already tried it.

--Steve

[Steve Phillips]

Progress:

I assumed that I could use  so I jumped to https://github.com/golang/go/wiki/GccgoCrossCompilation#symlink and followed those instructions.  I then compiled with gcc, gccgo, and ar all symlinked to a place in my $PATH that occurs before the non-mips gcc etc programs.

After compiling by running

    $ gccgo -Wall -o hello-sym hello.go -static-libgo

then running hello-sym on the target system, I get this error:

can't load library 'libgo.so.7'

Helpfully, in  it says that I can compile the binary statically "by adding the -static switch to gccgo".

Perfect!  So then I compiled with

$ gccgo -Wall -o hello-sym-static hello.go -static-libgo -static

scp'd the resulting hello-sym-static binary to the target machine, and run it.  The result?

$ ./hello-sym-static

Segmentation fault

Any idea what could be causing the segfault?  (hello.go is a trivial "Hello, world!" program.)

On the target (mips) device, I see files like /lib/libuClibc-0.9.33.2.so, with /lib/libc.so.0 being a symlink to /lib/libuClibc-0.9.33.2.so, in case that's relevant.

Thanks!

--Steve

[kty...@gmail.com]

Do you need gccgo, cgo or cross compiling?

I don't know about that, but otherwise  the default compiler should work for

mipsle (32 bit little endian)  "since" go 1.8.

Without FPU however you will get "illegal instruction" when running the binary.

There are 2 possibilities:

Wait for vstefanovic to submit his changes promised in issue 18162

or compile a kernel with FPU emulation support.

The latter worked for me on a vocore2 pc.

[Steve Phillips]

Do you need gccgo, cgo or cross compiling?

Cross-compiling.  I'm trying to cross-compile Go programs from an x86_64 Linux machine to run on a MIPS (32-bit) target machine with no software and no hardware FPU.

Without FPU however you will get "illegal instruction" when running the binary.

I am indeed getting the "Illegal instruction" error... but I'm compiling using gccgo, and I thought that would work?  Will it not since there's no FPU?

[Either w]ait for vstefanovic to submit his changes promised in issue 18162

I've pinged him and mentioned this thread at https://github.com/golang/go/issues/18162 ; thanks!

 

or compile a kernel with FPU emulation support.

I'll look more into doing exactly this, thank you.

--Steve