4ad / go

Go development tree for the sparc64 port
BSD 3-Clause "New" or "Revised" License
19 stars 11 forks source link

Linux/sparc64 port #18

Open glaubitz opened 7 years ago

glaubitz commented 7 years ago

Hi!

I'm opening this issue to be able to track the efforts for porting Go to Linux/sparc64.

For the porting work, I suggest using Debian unstable for sparc64 rather than Oracle's Linux for SPARC, mainly because the former has a much more up-to-date package base with a current kernel, toolchain and userland.

As sparc64 is currently not an official Debian release architecture, there are no official Debian installer images for sparc64. However, we're constantly working to improve sparc64 support in Debian which also includes regular beta installer images. These images can be downloaded from (new location as of 2017-10-27) [1].

Update 2017-10-21: The installation images now have been polished enough that no additional manual work is needed to install Debian on sparc64.

When asked for a repository mirror, add: http://ftp.ports.debian.org, directory: /debian-ports/

For any issues with Debian sparc64, please don't hesitate to contact us:

We're happy to help with any issues any time.

Thanks, Adrian

[1] https://cdimage.debian.org/cdimage/ports/

glaubitz commented 7 years ago

Update as of 2017-10-27: New location for installation images: https://cdimage.debian.org/cdimage/ports/

glaubitz commented 7 years ago

I have begun adding the initial bits for linux/sparc64:

https://github.com/glaubitz/go/commit/0eca2c04e3a3707ca9e85f524c7ea1e13a8873eb

It's still missing the stuff from src/runtime. I copied the syscall stuff from Debian's golang-golang-x-sys package here:

https://anonscm.debian.org/cgit/pkg-go/packages/golang-golang-x-sys.git/tree/unix

@jrtc27 has contributed fixes to libgo/gccgo and the golang-golang-x-sys package. As far as I know, all of these changes have been merged upstream (the x-sys stuff in a separate repository is located somewhere else where I cannot find it, but Ian Lance Taylor/James Clarke should know).

4ad commented 7 years ago

Thanks, I commented on the change itself.

glaubitz commented 7 years ago

I'm waiting for James Clarke (@jrtc27) to comment on this. He's done a fair bit of the stuff in x/sys.

KireinaHoro commented 6 years ago

Well, how to build? Bootstrapping with gccgo-6 will complain "unknown architecture: sparc64".

KireinaHoro commented 6 years ago

Seems like it's the src/cmd/dist/util.go that's missing the sparc64 goarch.

glaubitz commented 6 years ago

Did you actually switch to the sparc64-linux branch? The Linux port isn't part of the main branch.

The file you mentioned contains sparc64 for the default unix system:

https://github.com/4ad/go/blob/sparc64-linux/src/cmd/dist/util.go#L453

KireinaHoro commented 6 years ago

My fault. I've switched to sparc64-linux branch.

https://github.com/4ad/go/blob/sparc64-linux/src/runtime/defs_linux_sparc64.go is failing to build with borked nested /* */ style comments (seems like the header that was used to generate this go file contains block comments itself; these comments have to be adapted or removed); and removing those reveals other problems, namely undefined C structs with bogus names:

/root/golang-sparc/src/runtime/defs_linux_sparc64.go:221: undefined: _Ctype_struct___4 
/root/golang-sparc/src/runtime/defs_linux_sparc64.go:222: undefined: _Ctype_struct___5
/root/golang-sparc/src/runtime/defs_linux_sparc64.go:223: undefined: _Ctype_struct___6
glaubitz commented 6 years ago

You misunderstood, this isn't a finished project. This is a work-in-progress Linux port.

If it was finished, it wouldn't be living in a separate branch.

zenmetsu commented 4 years ago

My most sincere apology for necro'ing this issue, but it was still open and related to my issue...

There haven't been any updates to the code, so I don't know if this branch has been abandoned. I'm trying to bootstrap linux/sparc64, either on my sparc64 machine or my amd_64 machine, and I'm not having much luck in either case.

Building the bootstrap seems to work on the amd_64 host until I get this:

...
cmd/compile/internal/amd64
cmd/compile/internal/arm
cmd/compile/internal/arm64
cmd/compile/internal/ppc64
cmd/compile/internal/mips64
cmd/compile/internal/s390x
cmd/compile/internal/sparc64
cmd/compile/internal/x86
cmd/compile

##### Building packages and commands for linux/sparc64.
os/dir_unix.go:11:2: found packages syscall (creds_test.go) and unix (syscall_linux_sparc64.go) in /root/go/src/syscall
can't load package: os/dir_unix.go:11:2: found packages syscall (creds_test.go) and unix (syscall_linux_sparc64.go) in /root/go/src/syscall
4ad commented 4 years ago

Hello, this is expected, unfortunately. The port only exists for Solaris. Making it work on Linux is possible of course, but it requires some serious amount of work.

zenmetsu commented 4 years ago

Well that's unfortunate. So currently it is not possible to build the bootstrap for linux/sparc64 natively OR on x86? Is that correct?

4ad commented 4 years ago

Yes, it's not possible to bootstrap anywhere. The problem is not of bootstrapping nor of building. The linux/sparc64 port simply doesn't exist. This work only implements the solaris/sparc64 port.

glaubitz commented 4 years ago

Well, the port exists partially, to be more precise. I'm not an expert on the Golang code, but I would assume it won't take much to get it working on Linux/sparc64 and I already implemented some of the stuff.

I would say most heavy lifting is done in the OS-independent SPARC code and that has already been implemented.

4ad commented 4 years ago

Sure, but the work to bring it on Linux is non trivial. It's about a week of work for someone already experienced in Go internals. It's not that much, but it's still something that needs to be done.

cross commented 1 year ago

I have a need for golang on OpenBSD sparc64. I saw comments earlier that both OpenBSD and Linux were planned/desired, but needed some work to be done. From the above, I assume they're both in that same camp. It's 2.5 years later and on the other side of the pandemic, is there any lead on work on this front? I'd be happy to contribute, but am a C developer not go. :-)

4ad commented 1 year ago

This work has been abandoned for over 5 years ago now. Getting it back into a usable state would be a massive undertaking.