From owner-freebsd-emulation Wed Sep 1 22: 2:15 1999 Delivered-To: freebsd-emulation@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 0206F14D68 for ; Wed, 1 Sep 1999 22:02:11 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id BAA17295; Thu, 2 Sep 1999 01:01:43 -0400 (EDT) (envelope-from luoqi) Date: Thu, 2 Sep 1999 01:01:43 -0400 (EDT) From: Luoqi Chen Message-Id: <199909020501.BAA17295@lor.watermarkgroup.com> To: nox@jelal.kn-bremen.de, wine-devel@winehq.com Subject: Re: wine signal handlers lose %fs on FreeBSD Cc: freebsd-emulation@FreeBSD.ORG Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Here's a strange one: Sometimes apparently wine's signal handlers receive > %fs messed up (zeroed actually) and therefore crash/hang on FreeBSD > (3.2-stable, wine current-cvs). Patch this and watch for > `warn:seh:EXC_SaveContext teb=0xsomewhere teb_sel=something, fs=0, gs=foo' > messages, teb_sel is what fs really should have been (and what is loaded > back there after the message, so the program actually continues too.) > > Any idea/explanation from the experts? I have looked at the sources a bit > but came up empty. (well i found out that fs and gs aren't set/used in > the sigcontext struct for non-vm86 processes but wine knows that and simply > uses the registers directly, and i couldn't find anything that looked like > it would change them on the way into and out of the signal handler, or > anywhere else in the kernel for that matter...) > The kernel sets %fs to 0 during a context switch if it triggers a fault (protection fault or segment not present) and signals SIGBUS. Most likely the EXC_segv in your previous email is this signal. Unfortunately there is no easy way to know which %fs value is causing the fault (probably you could add a kernel printf, in file sys/i386/i386/trap.c, search for cpu_switch_load_fs). I took a brief look at the exception code, it probably would not work under 4.0-current because the kernel uses %fs and signal handlers are called with a default %fs value (the same as the default %ds). You might need to restore %fs from the value in sigcontext at beginning of your signal handlers (yes, fs in sigcontext is set for 4.0-current. Regarding this, we could change the kernel, both -current and -stable, so that fs/gs are always saved in sigcontext when the signal is delivered, and restored during the signal trampoline, hence a consistent interface to application authors). Alternatively, we could change the kernel to call signal handlers with the original fs. > Btw could someone please subscribe this address to -emulation for me? > freebsd-emulation-l@jelal.kn-bremen.de (which is a local mailpost alias > in case anyone wonders, i prefer reading the lists with trn...) > > I mailed majordomo with this a while ago (and yes i did send the auth > command back :) but alas, no messages. > This is a low traffic list, chances are there were no messages... -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message