2.6.16 for linuxulator & 7.0 release

[Jung-uk Kim]

On Tuesday 20 March 2007 09:40 am, Tijl Coosemans wrote:
> 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.i4GMhvhh0371
> > > >47
> > >
> > > 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...

Yes, sysarch(2) should do.  You should never rely on GDT entries for 
anything on amd64.

Jung-uk Kim