Besides %gs fix that was done by creating code stubs and rewriting offending instruction with jmp 32bit rel (or constantly catching SIGSEGVs if the offending instruction is 4 bytes or less), there was also an issue with SIGUSR1.
Chrome's/Electron's processes are very active and they are constantly waking/checking each other's thread. OpenBSD does not like it unless you allow global ptrace (and the goal was to keep OpenBSD as stock as possible).
With those two things fixed along with some compile time issues and love to pulseaudio code in wine to correct for coarse timers in OpenBSD (sound worked perfectly on 1000Hz kernel, but again, we wanted stock)  we could start wine and run most 64 bit apps without any issues.

32 bit apps are likely no go as they require user LDT, even if you can use WOW64. 32 bit instructions are decoded as different instructions in 64 bit (INC/DEC in 32bit mode, but just a REX prefix in 64 bit for example) so code will likely not fault immediately but keep running garbage for good few instructions before it fails with #UD/#GP -> SIGILL/SIGSEGV.

Fixing it will definitely require JIT approach like DOSBOX did for non OpenBSD builds.

In short, we got extremely lucky that %gs always pinned to 0, and I haven't found yet any access to %gs that gets outside of page 0 - TEB itself is at most 0x2000 bytes. Not that lucky with 32 bits.

I was asking about %gs because patch itself is pretty heavy and has zero chance to go upstream into Wine. And I was told that if we can't "fix" %gs (there is nothing to fix in OpenBSD, swapgs/setgsbase can be a security issue) then there is no point in pushing changes that even make Wine compile on OpenBSD. It is understandable, since then they will have to support code that does not run.

Thanks for your input! I joined mailing lists just few weeks ago so I haven't dove deep into the mailing list history


On Tuesday, October 13th, 2026 at 9:03 AM, vl <vl_ms@disroot.org> wrote:

> Sorry, I'm a little late to the conversation.
> Some months ago when I saw that they figured out how to run 32 bit stuff
> without 32 bit libs, I wondered what other things were the wine
> blockers.
> So I spent a few days figuring out what was required to get openbsd-wip
> attempt from 2022 to compile. You can see me asking "man & ports
> llvm clang missing some built-in headers?" in misc, which was one of the
> first issues I encountered. After assembling some patches and finally
> getting it to compile, I faced a coredump with a peculiar message on
> which I wasn't sure how to proceed, as I hit the limit of my competency.
> I guess the man with the llm beat me to the race (I wasn't using
> anything besides the nearly unavoidable ones in search results). Looking
> at wip activity from yesterday, I guess my efforts are
> no longer needed and I can move on to testing games and reporting my
> results. And yeah, neither page 0 nor user ldt are required for some
> years. Seems this %gs issue is the last one standing.
> 
>