On Tue, 13 Oct 2026 09:17:30 +0000
Neth Iafin <NethIafin-obsd@proton.me> wrote:

> 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.
> > 
> >   
> 

Oh, if we're going to have to write a JIT for 32 bit stuff Haiku
people may be interested in that, too. At first I assumed ARM Macs
can't run 32 bit x86 with Rosetta, but apparently they can. Just a
thought on who may help.

I'm rather new here, too, nice to meet you.