[ktrace.out](/uploads/8eba380b19d6da55e6c10d7488da9554/ktrace.out) [mmap-modernc.go](/uploads/ef512e66821aadd1c120558f5b987170/mmap-modernc.go) On 2021-12-23, a new syscall for `mmap` was introduced: ``` 49 STD NOLOCK { void *sys_mmap(void *addr, size_t len, int prot, \ int flags, int fd, off_t pos); } ``` At the same time, the existing `mmap` syscall was renamed from `sys_mmap` to `sys_pad_mmap` (since it contains a now-obsolete argument for padding). See `sys/kern/syscalls.master`: https://github.com/openbsd/src/commit/1d60349d0b961891264d426ffe1c0ced24b2374c#diff-e8c6a075c6e1240e27216779540b66f3db43b14a3b3615c2ecb7a111faa54504 On 2023-02-11, the original mmap syscall was retired entirely: https://github.com/openbsd/src/commit/8c7f5cc47d34f1bd83a08278dad544a34184dabf With the release of OpenBSD 7.3 on 2023-04-10, any go program that uses mmap on OpenBSD will crash with `SIGSYS`. Looking at https://gitlab.com/cznic/libc/-/blob/v1.22.3/libc_openbsd.go it seems the argument list was updated correctly, but it's using the wrong syscall number (`unix.SYS_MMAP` is `197`, but it should be `49`). I've filed a ticket against go to fix that: https://github.com/golang/go/issues/59661 Attached is a test program and the output from `kdump`. The failure snippet in question is: ``` 1487 mmap-modernc CALL (via syscall) #197 (obsolete pad_mmap)() 1487 mmap-modernc PSIG SIGSYS caught handler=0x4611a0 mask=0<> 1487 mmap-modernc RET #197 (obsolete pad_mmap) -1 errno 78 Function not implemented ``` FWIW, the `unix.Mmap` function from `golang.org/x/sys/unix` works as expected.