>On Wed, 8 Dec 1999, Linus Torvalds wrote:
>> The same is true of Wine: you just need to check the DS/SS segment values
>> on return (and if they are anything but USER_DS you need to use "iret"
>> again).
>whoops, nasty. I'm not quite sure how we could do this though - SYSENTER
>destroys CS and SS, so we have nothing to check ... Probably Wine has to
>use the old int $80 interface?
Maybe I can clarify the use of non-standard segments within Wine:
While we have to load non-standard selectors into the segment registers
when executing 16-bit Windows code, the standard values are always restored
by the Wine 16<->32 bit glue code before we call any library routine or
perform a syscall. (glibc would get quite confused anyway if called with
a non-standard selector loaded in %ds, as it couldn't access its own
global data etc.)
There is just one point where we need OS assistance in managing segments:
If a signal arrives while the Wine process is currently executing 16-bit
code, we need the OS to switch the segment registers back to the standard
settings before executing the signal handler. Similarly, the sigreturn
code would then need to restore the segment registers before continuing
to execute the interrupted 16-bit code. In special cases, e.g. when the
signal triggers the Wine-internal debugger, we might even want to *change*
the selector values in the context structure passed to the signal handler,
and have the OS reload those changed values before resuming execution.
All this works fine currently.
If I understand the signal handling mechanism in Linux correctly, return
from a signal handler works by performing a sigreturn syscall. As this
syscall will need to return to 16-bit code with non-standard segment
registers, using a SYSENTER/SYSEXIT mechanism would appear problematical
in this case. All *other* syscalls should pose no problem even under Wine,
however.
[ There's one special use of segment registers by Wine even when executing
32-bit code: Windows apps require that the %fs register points to a
thread information block containing essential parameters related to the
current thread, e.g. thread ID, thread-local storage, exception handler
chain etc. For efficency reasons we keep that value loaded into %fs
throughout the execution of Wine, even while performing glibc calls or
syscalls. As %fs is not normally used by any library, this doesn't
hurt currently.
However, even when switching to a SYSENTER/SYSEXIT syscall mechanism,
this should pose no problem, I think, as those instructions don't treat
%fs in any special way ... ]
Bye,
Ulrich
-- Ulrich Weigand, IMMD 1, Universitaet Erlangen-Nuernberg, Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/