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 #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 (#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:

1. Land the above SDYNIMPORT changes and get the port operational again.
2. Revisit switching to external linking
3. 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.