Many thanks @sthen for the heads up and the patch!

A couple of questions:

• do you have a reference I can point people to if they ask me more details?
• have you raised this in the cosmopolitan repo too? It'd be great if there was an issue I can subscribe to, so if/when this is fixed we can update the cosmocc version and verify whether we can add back support for 7.5+

They're slightly off with the version number, but https://github.com/jart/cosmopolitan?tab=readme-ov-file#support-vector says "7.3 or earlier", and that's because of this issue.

There is an issue open at jart/cosmopolitan#1263, it covers a few different things though;

• these syscall() restrictions
• cosmocc's polyglot APE programs rely on the shell executing scripts with NULs in a place that AIUI is not allowed by posix even with the change they had Austin Group make for them (it ended up as "allow execution if the initial part intended to be parsed by the shell consists of characters and does not contain the NUL character" - they do have NULs before the part that needs to be parsed by the shell as part of the Windows PE section). these won't run on OpenBSD /bin/sh, though there's a workaround of running under bash/zsh
• newer OpenBSD versions enable branch-target control flow restrictions by default on amd64 and aarch64 where available on the CPU, unless the executable has a note section opting-out - so either the note section needs adding, or "landing pads" (depending on arch, endbr / bti c) adding

I didn't look too deeply into how cosmocc handles syscalls on various OS but I suspect that the only way to get it working on modern OpenBSD would be for the extracted binary to call into libc stubs rather than using syscall() itself - Go did this, for example (golang/go#63900)

The best reference for how the restriction mechanism works is possibly https://marc.info/?l=openbsd-tech&m=170205367232026&w=2

Awesome, TY! I subscribed to the issue and will follow related updates to make sure we stay aligned with supported versions 🙏