Date: Tue, 20 Mar 2007 14:40:04 +0100 From: Tijl Coosemans <tijl@ulyssis.org> To: freebsd-emulation@freebsd.org Cc: Alexander Leidinger <Alexander@leidinger.net>, rdivacky@freebsd.org, kib@freebsd.org, Jung-uk Kim <jkim@freebsd.org> Subject: Re: 2.6.16 for linuxulator & 7.0 release Message-ID: <200703201440.06452.tijl@ulyssis.org> In-Reply-To: <200703191618.14204.jkim@FreeBSD.org> References: <20070316120038.2iizia24mc4wcw8s@webmail.leidinger.net> <200703191819.31766.tijl@ulyssis.org> <200703191618.14204.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 19 March 2007 21:18:11 Jung-uk Kim wrote: > On Monday 19 March 2007 01:19 pm, Tijl Coosemans wrote: > > On Monday 19 March 2007 17:13:28 Jung-uk Kim wrote: > > > On Saturday 17 March 2007 09:29 am, Tijl Coosemans wrote: > > > > On Friday 16 March 2007 12:00:38 Alexander Leidinger wrote: > > > > > In p4 we have the futex/TLS stuff for amd64 but because of > > > > > the futexes not completely right part it is not committed to > > > > > current yet. As we already have the futex and TLS stuff for > > > > > i386 on a similar level in current, I would say we should go > > > > > ahead and sync the amd64 stuff. It is not used by default, so > > > > > we don't break existing linux stuff and we get the benefit of > > > > > more people being able to have a look at it and play with it. > > > > > So what are your opinions, shall we give jkim@ the green > > > > > light to MFp4 the futex/TLS stuff? > > > > > > > > You should let an amd64 guru review the tls part in imho. I > > > > don't think you can remove these lines for instance: (from > > > > linuxolator-p4.diff) > > > > > > > > --- sys/amd64/amd64/cpu_switch.S.orig > > > > +++ sys/amd64/amd64/cpu_switch.S > > > > @@ -104,11 +104,12 @@ > > > > testl $PCB_32BIT,PCB_FLAGS(%r8) > > > > jz 1f /* no, skip over */ > > > > > > > > - /* Save segment selector numbers */ > > > > - movl %ds,PCB_DS(%r8) > > > > - movl %es,PCB_ES(%r8) > > > > - movl %fs,PCB_FS(%r8) > > > > [...] > > > > - /* Restore segment selector numbers */ > > > > - movl PCB_DS(%r8),%ds > > > > - movl PCB_ES(%r8),%es > > > > - movl PCB_FS(%r8),%fs > > > > > > Actually it was dead code, i.e., PCB_32BIT flag was never set > > > from anywhere at all. I believe it was part of peter's > > > experiment, which was never materialized: > > > > > > http://docs.freebsd.org/cgi/mid.cgi?200405162243.i4GMhvhh037147 > > > > Ah, thanks for clearing this up. So if I understand this correctly, > > %fs is never preserved right? That's one big cause of trouble for > > win32 programs then. > > Correct. If you load %gs, %fs, or any other segment registers from > user land (e.g., movw %eax, %gs) and use it (e.g., movw %gs:0, %eax), > you are doomed. > > > That log entry mentions to do it ``at user<->kernel transition''; > > that's where it happens in the i386 kernel. Those 3 segment > > registers are pushed on the stack there (in exception.s). Could > > something similar be done on amd64 then? > > Yes, something similar can be done. However, I believe peter chose > different design, i.e., disregarding segment registers because amd64 > can do flat memory addressing, which significantly simplifies design. > Only base addresses for %fs and %gs are preserved via MSR. If you > want to preserve this behavior and to support segment registers in > compatibility mode, you cannot prevent significant context switching > overhead. Ok, that should work. The problem is that Wine currently makes some assumptions about the use of %fs just like glibc does about %gs. This is kind of the same problem you had when implementing linux TLS on amd64. Wine could be patched to never write to %fs (and %gs) and to make use of i386_set_fsbase() instead. Something to add to my todo list...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703201440.06452.tijl>