Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net: Gccgo port for aix/ppc64 #31382

Open
Helflym opened this issue Apr 10, 2019 · 5 comments
Open

x/net: Gccgo port for aix/ppc64 #31382

Helflym opened this issue Apr 10, 2019 · 5 comments

Comments

@Helflym
Copy link
Contributor

@Helflym Helflym commented Apr 10, 2019

I'm currently porting x/net for aix/ppc64 for GC implementation (https://go-review.googlesource.com/c/net/+/170557). I was aiming to port it for Gccgo implementation as well.

In my understanding, for most of the OSes, a package implementation doesn't need to be changed according to which compiler is being used.
The only case, I'm thinking of, where a special file is needed is for Oses (like AIX, Solaris and maybe 1.12 Darwin) which haven't the same syscall backend. On Linux or BSDs, syscall.Syscall can be called from both Gc and Gccgo. Correct me if I'm wrong.

But on AIX, Gc syscalls needed //go:linkname and Gccgo ones needed //extern. Therefore a different syscall file is needed. However, the rest of the package should remain unchanged right ?

Note I've checked with gccgo-8 (go1.10) on Linux/amd64 and x/net package tests seems to pass as is.

@ianlancetaylor could you please confirm than these are the only different between Gccgo and Gc compiler on a package implementation ?

CC @mikioh

@gopherbot gopherbot added this to the Unreleased milestone Apr 10, 2019
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 10, 2019

On most Unix-like systems, gccgo code can call syscall.Syscall just as gc code can. The issue where I suggested using //extern was not calling syscall.Syscall directly.

Does syscall.Syscall work on AIX?

@Helflym
Copy link
Contributor Author

@Helflym Helflym commented Apr 10, 2019

No, it doesn't work. That's why a new file with //extern is needed in order to provide syscall on AIX.
But the remain code will work as is, isn't it ?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 10, 2019

Sorry for forgetting about syscall.Syscall. Yes, as far as I know, the other code should work fine with both gc and gccgo.

@mikioh
Copy link
Contributor

@mikioh mikioh commented Apr 12, 2019

@Helflym,

I think there are two issues: one is a technical thing and another is an operation thing. Perhaps the latter might be a bit heavy for people who need to work on release engineering, for example, spinning up a new gccgo builder fleet, making sure the maintenance window for both go and gccgo released versions, blah blah. Looks like this issue focuses on the former, so please open a new issue for the latter, as a proposal, like "proposal: x/net or all?: add support for gccgo".

And this issue also must be a proposal?

PS: What happens when we use a pair of x/net-gccgo and stdlib-go or vice versa? Does a single executable file containing two different runtimes, go and gccgo, just work fine?

@Helflym
Copy link
Contributor Author

@Helflym Helflym commented Apr 12, 2019

Ok I now understand the underlying problem. As far as I know, there is no builder for gccgo, and the core team assume that if it works on Gc and it should work on Gccgo too. Because as I say, every x packages (expect x/sys/unix) will work as is on both Gc and Gccgo. I'll open an issue to know how checks are made on gccgo for these x packages.

As far as I know, it's not possible to build an executable with x/net-gccgo and a stdlib-go. Both built packages aren't stored at the same place and are completely independent. If you build an executable with x/net and gccgo, I'll have the gccgo runtime/packages.

@mikioh mikioh modified the milestones: Unreleased, Gccgo Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants