x/net: Gccgo port for aix/ppc64

[Helflym]

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

[ianlancetaylor]

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]

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]

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

[mikioh]

@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]

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.