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
Comments
On most Unix-like systems, gccgo code can call Does |
No, it doesn't work. That's why a new file with //extern is needed in order to provide syscall on AIX. |
Sorry for forgetting about |
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? |
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. |
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
The text was updated successfully, but these errors were encountered: