The openbsd/mips64 port is currently in limbo - this issue is an attempt to identify a path forward.
Background
OpenBSD 6.9 (May 2021) onward requires that system calls be made via libc stubs - direct system calls are no longer permitted (see https://github.com/golang/go/issues/36435 for more details). The openbsd/amd64 and openbsd/arm64 ports were converted in Go 1.16, while openbsd/arm and openbsd/386 were converted early in Go 1.17.
The only port not converted is openbsd/mips64 - this was in part due to the lack of support for SDYNIMPORT with internal linking. An initial conversion was done which required external linking (https://go-review.googlesource.com/c/go/+/342510), however among other issues, this meant that the misc-compile-openbsd would not be able to compile test openbsd/mips64 - it was suggested that internal linking with SDYNIMPORT would be a better route.
The last OpenBSD release that Go tip works on for openbsd/mips64 is OpenBSD 6.8, which has been EOL since October 2021. To further complicate matters, a working version of the port has been maintained in the OpenBSD ports tree (https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/go/). For this port to be useful, other repositories like golang.org/x/sys/unix have needed to switch to indirect system calls, which has further broken openbsd/mips64 in Go tip (https://github.com/golang/go/issues/58110).
Aside from the openbsd/mips64 port being broken, it also means that the indirect syscall migration cannot be completed and there is various technical debt lingering from this in the Go runtime/linker. The builder is also currently offline.
Current Status
Changes to implement SDYNIMPORT with both internal and external linking were mailed in July 2022 (https://go-review.googlesource.com/c/go/+/415815) - these two changes are ~320 lines of code combined. A year and two full Go release cycles later, the openbsd/mips64 port is still blocked on the second of these changes (the first landed during the previous release cycle).
Moving Forward
There are at least three potential resolutions:
- Land the above
SDYNIMPORTchanges and get the port operational again. - Revisit switching to external linking
- Decommission the port
(1) would be preferable as it would allow the port to become functional again, however it is unclear when this may occur. The openbsd/mips64 port is a second class port and mips64 is not a first-class architecture - this seems to be part of the reason why it is difficult to get reviews, however the flip side of this is that it has not lowered the review bar and/or provided any way to progress.
(2) avoids changes to the Go linker, instead switching the port entirely to external linking - this means that builds take longer, the misc-openbsd-compile target is unable to test openbsd/mips64, but the port can become functional again.
(3) given that the port is broken and that it is preventing technical debt from being cleaned up, decommissioning is an option. This is a last resort, however it seems preferable to the current state.
If (2) or (3) are preferred I can send appropriate changes for review.
Comment From: seankhliao
cc @golang/compiler
Comment From: bcmills
(CC @golang/openbsd @golang/mips)
Comment From: rsc
It sounds like the main request here is some reviews for the stack at https://go-review.googlesource.com/c/go/+/512475/1.
Comment From: gopherbot
Change https://go.dev/cl/516016 mentions this issue: runtime,syscall: invert openbsd architecture tests
Comment From: 4a6f656c
@cherrymui @mknyszek @rsc has there been any further consideration here, given the imminent freeze?
Comment From: 4a6f656c
Given that the port has been completely broken for more than two years and there has been no further response on this issue for well over a year, I'm going to declare the openbsd/mips64 port dead.
Comment From: gopherbot
Change https://go.dev/cl/649659 mentions this issue: runtime: remove openbsd/mips64 related code
Comment From: AlekSi
Given d5dc36a / CL above, should this issue be closed?
Comment From: 4a6f656c
Given d5dc36a / CL above, should this issue be closed?
No, not really - that only cleans up part of the port.
Comment From: gopherbot
Change https://go.dev/cl/693880 mentions this issue: syscall: simplify execve handling on libc platforms